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PREFACE 


The  rapid  integration  of  Interactive  Electronic  Technical  Manuals  (lETMs)  into  military 
workspaces  throughout  the  Department  of  Defense  has  created  an  opportunity  to  enhance  the 
comprehensive  instmction  provided  to  students  of  Defense  Acquisition  University  (DAU) 
courses  and  to  members  of  the  defense  acquisition  workforce.  The  swift  pace  of  lETM 
development  in  the  1990s  by  each  of  the  Services  made  preparation  of  a  single  guide  on  the 
subject  a  daunting  task. 

This  guide  is  the  product  of  joint  Defense  Acquisition  Research  effort  sponsored  by 
Offices  at  Defense  Systems  Management  College  (DSMC),  including  the  Research,  Consulting 
and  Information  Dissemination  Division,  the  Program  Management  and  Leadership  Department, 
and  the  Logistics  Management  Department  of  the  Faculty  Division.  A  strong  core  of  the 
research  team  included  members  from  the  Advanced  Engineering  &  Research  Associates,  Inc. 
Orlando  Florida,  who  were  instmmental  in  conducting  the  literature  search,  surveys,  and 
interviews,  and  integrating  the  results  into  this  useful  instructional  tool  and  reference.  The 
Institute  for  Defense  Analysis  conducted  technical  reviews  and  provided  expert  advice. 

Designed  for  use  in  DAU  courses  and  as  an  aid  to  acquisition  managers,  the  text  initially 
assumes  the  reader  has  little  familiarity  with  lETMs.  It  presents  fundamental  material,  then 
addresses  issues  of  immediate  concern  to  the  acquisition  managers  from  both  the  government 
and  industry  perspective. 

Comments  and  recommendations  relating  to  the  overall  text.  Service-specific 
information,  or  technical  developments  are  solicited.  Send  them  to: 

Defense  Systems  Management  College 

ATTN  Logistics  Management  Department  (FD-LM) 

9820  Belvoir  Road,  Suite  3 
Fort  Belvoir,  Virginia  22060-5565 

Phone:  703-805-4658 
Fax#:  703-805-3709 
e-mail:  riffeej@dsmc.dsm.mil 


Paul  T.  McMahon 
Associate  Dean,  Research 
RCID 


Norman  A.  McDaniel 
Chairman, 

Program  Management  & 
Leadership  Department 


John  Riffee 
Chairman, 

Logistics  Management 
Department 
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CHAPTER  1 
INTRODUCTION 


1.1  Objective 

This  document  is  designed  to  be  the  primary  desk  reference  for  acquisition  personnel  who  will  be 
required  to  acquire,  develop,  deliver  and/or  manage  lETMs.  It  incorporates  the  status  of 
existing/planned  DoD  and  Service-unique  policy  guidance;  discusses  current  and  projected 
technologies  related  to  the  production  of  lETMs;  analyzes  the  relationship  between  lETMs  and 
training;  and  addresses  delivery  vehicles  —  including  the  World  Wide  Web  (WWW). 

1.1.1  Background 

An  emerging  area  of  technology,  the  acquisition,  development,  deployment  and  sustainment  of 
electronic  technical  documentation  and  associated  multimedia  elements  has  rapidly  gained 
acceptance  throughout  all  branches  of  the  military.  The  explosion  in  popularity  of  the  Internet  has 
produced  an  insatiable  appetite  for  near  real-time  information  needs.  The  demand  by  today’s 
computer-literate  society  is  for  electronic  media,  not  paper  copy.  Faced  with  shrinking  defense 
budgets,  weapon  system  managers  have  turned  to  one  small  comer  of  the  information  spectmm  to 
meet  its  technology  needs.  The  Interactive  Electronic  Technical  Manual  (lETM),  first 
conceptualized  in  thel980s,  became  a  reality  by  the  early  1990s.  In  just  the  past  few  years, 
advances  in  computing  power,  increased  functionality  in  lETM  delivery  software,  portability  of 
computers  and  reduced  lETM  development  costs  have  paved  the  way  for  a  successful  electronic 
documentation  delivery  and  sustainment  program. 

Simply  put,  an  lETM  is  a  technical  manual  that  is  prepared  (authored)  in  digital  form  on  a  suitable 
medium,  by  means  of  an  automated  authoring  system.  It  is  designed  for  an  electronic-window 
display  to  a  user,  and  in  most  cases  it  possesses  the  following  three  characteristics: 

•  The  format  and  style  of  the  presented  information  are  optimized  for  window  presentation  in  an 
electronic  form,  either  on  a  desktop  PC,  laptop  PC,  or  other  portable  electronic  display  device. 
And,  it  is  designed  to  assure  maximum  comprehension.  That  is,  the  presentation  format  is 
"frame-oriented,”  not  "page-oriented.” 

•  The  elements  of  technical  data  constituting  the  lETM  are  so  interrelated  that  a  user's  access  to 
required  information  is  facilitated  to  the  greatest  extent  possible,  and  is  achievable  by  a  variety 
of  paths. 

•  The  computer-controlled  lETM  display  device  can  function  interactively  (as  a  result  of  the 
user’s  request  and  information  input)  in  providing  procedural  guidance,  navigational  directions, 
and  supplemental  information.  It  can  also  provide  assistance  in  carrying  out  logistic-support 
functions  supplemental  to  maintenance. 

Not  all  lETMs  fit  the  three  criteria  stated  above.  lETMs  can  range  from  raster-scanned  images  to 
sophisticated  database  management  systems  using  expert  systems  and  diagnostics.  Using  a  strict 
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definition  of  lETMs,  some  digitized  manuals  should  be  referred  to  as  Electronic  Technical  Manuals 
(ETMs).  The  term  electronic  technical  manual  (ETM)  generally  describes  all  combinations  of 
technical  manual  data  in  digital  formats,  stored  in  optical  or  magnetic  media,  and  viewed  through 
electronic  display  devices.  To  avoid  confusion,  the  more  commonly  used  term  lETM  will  be  used 
throughout  the  DSMC  lETM  Guide  to  describe  all  forms  of  digital  technical  manuals  (TMs). 

By  the  mid  to  late  1990s,  pilot  programs  emerged  that  coupled  lETMs  with  multimedia  training 
elements.  The  combination  of  electronic  documentation  with  a  multimedia  editing  and  delivery 
system  established  the  building  blocks  necessary  for  an  Electronic  Classroom  (EC)  environment. 
Armed  with  these  technologies,  military  trainers  now  had  the  opportunity  to  develop  more  effective 
classroom  instmction  that  could  be  extended  into  the  field  and  reused.  CD-ROMs  containing  entire 
technical  manuals  and  lesson  guides  can  now  be  provided  to  the  user  for  just-in-time  (JIT)  refresher 
training  upon  returning  to  their  duty  station.  The  use  of  these  Electronic  Performance  Support 
Systems  (EPSS),  where  lETM  technology  is  integrated  with  training  programs,  provides  the 
capability  to  improve  individual  performance  and  reduce  costs.  When  implemented  properly, 
streamlining  of  the  training  pipeline  can  be  accomplished. 

1.1.2  Scope 

The  DSMC  lETM  Guide  is  a  guidance  document  that  does  not  establish  policy  or  procedures.  Many 
lETM  requirements  are  Service-specific  and  have  been  identified  within  the  DSMC  lETM  Guide 
for  further  investigation  by  the  lETM  acquisition  manager.  This  guide  should  be  used  as  a  starting 
point  for  lETM  development  efforts  and  include  consultation  with  the  appropriate  Service’s  lETM 
points  of  contact  (identified  in  the  Appendices)  for  further  information  and  guidance.  Due  to  the 
dynamic  environment  surrounding  this  subject  matter,  the  contents  and  referenced  requirements  of 
this  document  will  require  periodic  modification.  Personnel  are  encouraged  to  access  the  latest 
version  of  the  DSMC  lETM  Guide  at: 

http://www.dsmc.edu/IETM/guide.htm. 

1.1.3  Organization  of  the  Guide 

The  lETM  Guide  is  presented  as  a  series  of  building  blocks  to  enhance  your  understanding  of  the 
lETM  life  cycle. 

Chapter  2  summarizes  the  benefits  of  lETMs  and  their  impact  on  logistic  support  systems. 

Chapter  3  summarizes  the  different  classes  of  lETMs. 

Chapter  4  provides  overall  lETM  acquisition  guidance. 

Chapter  5  reviews  pre-IETM  development  resources,  including  the  Government  Concept  of 
Operations  (GCO)  and  lETM  Concept  of  Operations  (CONOPS). 

Chapter  6  provides  an  overview  of  lETM  development,  including  developing  lETMs  from  legacy 
material  and  as  a  new  program. 
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Chapter  7  presents  a  discussion  on  the  future  of  lETMs  from  a  development  and  delivery 
standpoint. 

Appendix  A  reviews  lETM  software.  It  specifically  discusses  the  foundation  of  many  military 
lETMs:  SGML  (Standard  Generalized  Markup  Language).  The  chapter  introduces  a  structured 
document  approach  to  the  creation  of  technical  data  to  permit  the  electronic  interchange  of 
information  within  a  centralized  DoD  database. 

Appendix  B  addresses  the  Continuous  Acquisition  and  Life-cycle  Support  (CALS)  philosophy  and 
how  it  applies  to  lETMs.  It  also  provides  a  discussion  of  the  specifications  underlying  lETM 
development  and  delivery. 

Appendix  C  addresses  the  training  and  lETM  interface  between  products  such  as  Interactive 
Courseware  (ICW),  Computer-based  Training  (CBT)  and  Computer  Aided  Instruction  (CAI). 

Appendix  D  contains  Air  Force-specific  lETM  acquisition  information. 

Appendix  E  contains  Navy-specific  lETM  acquisition  information. 

Appendix  F  contains  Army-specific  lETM  acquisition  information. 

Appendix  G  contains  USMC-specific  lETM  acquisition  information. 

Appendix  H  presents  a  sample  lETM  Concept  of  Operations  (CONOPS),  which  is  defined  earlier 
in  the  text.  Additional  supporting  material  is  provided  in  subsequent  appendices. 

1.1.4  Roles  and  Responsibilities 

The  Program  Manager  and  respective  project  leaders  are  ultimately  responsible  for  ensuring  that 
requirements  and  missions  are  adequately  supported.  Each  program  should  establish  a  team  to 
research  and  develop  an  lETM  Concept  of  Operations  (see  Chapters  4  and  5)  to  define 
system/equipment  Operational  &  Maintenance  (O&M)  data  requirements  and  functionality  of 
lETMs.  The  Program  Manager  should  ensure  that  the  team  contains  adequate  representation  from 
program,  logistic  and  engineering  disciplines,  design  agents,  training,  and  user  activities.  Their 
functions  and  requirements  are  described  below. 

•  Program/Logistics  Element  Manager  -  The  acquisition,  technical,  and  functional  managers  are 
responsible  for  creating,  reviewing,  validating,  delivering,  maintaining,  and  updating  TMs  in 
any  format  and  for  implementation,  execution  and  management  of  EETM  processes  supporting 
the  weapon  systems  or  equipment;  provides  the  lETM  developers  with  engineering  and 
technical  data. 

•  Logistics  Support  (LS)  Manager  -  Responsible  for  ensuring  that  the  program  is  supported  with 
accurate  TMs  and  training;  leads  the  procurement  of  TMs,  training  and  courseware  materials  (if 
applicable),  and  monitors  the  process  and  progress  for  any  system  under  the  manager’s 
cognizance. 
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•  Program/Maintenance  Engineer  -  Defines  technical  requirements  for  the  program  system  and 
assists  in  interpreting  and  validating  technical  information  that  will  produce  the  TM  and 
courseware;  acts  as  the  Government  agent  for  technical  issues  and  provides  additional  technical 
support  functions. 

•  Design  Agent  (e.g.  contractor)  -  Provides  initial  technical  data  for  the  program  and  may  author 
the  lETM  content. 

•  Technical  Writer  -  Verifies  the  parts  of  the  TM  and  training  using  logistics  input  data,  and 
provides  proposed  changes  and  alterations  to  the  deliverable  products.  Provides  initial 
technical  data  for  the  program  and  may  author  lETM  content. 

•  Training  Agent  -  Provides  and  maintains  the  training  facility  and  curriculum  after  a  ready-for- 
training  date  has  been  reached. 

•  User  -  Personnel  who  use  the  TM  to  gather  information  or  perform  work  (e.g.,  maintainer, 
trainer,  or  operator). 
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CHAPTER  2 
BENEFITS  OF  lETMS 


2.1  Introduction 

Ever  since  the  Egyptians  invented  papyrus,  paper  has  been  used  to  deliver  information.  Although 
paper  remains  the  preferred  medium  for  certain  types  of  information  (novels,  personalized 
correspondence,  etc.),  electronic  alternatives  are  maturing.  The  average  military  inductee  is 
computer  savvy  and  experienced  with  the  Internet  and  can  easily  adapt  to  computer-delivered 
information. 

Today’s  paper-based  manuals  are  no  longer  the  optimal  choice  for  delivering  information  about 
complex  machinery.  Traditional  paper  manuals  present  a  wealth  of  problems,  including: 

•  Weight  -  Where  mobility  is  a  top  priority  (ships,  ground  based  units),  every  area  where  a 
reduction  in  weight  can  be  accomplished  is  scrutinized.  One  study  determined  that  an  Oliver 
Hazard  Perry  Class  frigate  (FFG  7)  contained  21  tons  of  paper  and  containers  for  paper 
storage.  An  AEGIS  Class  cmiser  (CG  47)  had  accumulated  37  tons. 

•  Volume  -  Paper  takes  up  much  needed  space  within  a  mobile  unit.  In  the  example  presented 
above,  assuming  a  density  of  40  pounds  per  cubic  foot,  the  frigate's  21  tons  of  paper  would 
occupy  1050  cubic  feet. 

•  Information  Access  -Technical  manuals  for  complex  equipment  regularly  extend  across 
multiple  volumes.  The  technical  manuals  for  the  LM2500  are  contained  in  1 1  volumes.  In  a 
typical  maintenance  action  where  the  technician  needs  to  diagnose  and  correct  a  problem, 
finding  the  correct  information  among  the  various  maintenance  volumes  can  take  a 
considerable  amount  of  time. 

•  Up-to-date  Information  -  Rapid  changes  to  military  equipment  through  modifications  and 
upgrades  require  supporting  documentation  to  be  updated  just  as  often.  Paper-based 
documents  require  a  series  of  change  pages  to  be  methodically  inserted,  pen-and-ink 
annotations  made  where  necessary,  and  superseded  information  discarded.  The  reduction  of 
personnel  within  the  military  leaves  little  time  to  accurately  incorporate  and  check  changes. 
This  can  result  in  incomplete  information,  incorrect  maintenance  actions  and  possible  safety 
problems. 

•  Printing  -  Paper  is  expensive  compared  to  electronic  documentation.  Technical  manual 
developers  spend  many  hours  formatting  a  document  (page  breaks,  widows/orphans)  to  fit  on 
8  1/2  X  11”  paper.  The  costs  of  printing  multiple  copies,  providing  binders  for  the  documents, 
and  shipping  to  multiple  destinations  also  have  to  be  considered. 

•  Deterioration  -  The  typical  harsh  military  environment,  with  daily  handling  by  technicians, 
gradually  deteriorates  the  paper  technical  manual. 
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2.2  Introduction  of  lETMs 


The  introduction  of  a  new  technology  into  the  military  is  not  accomplished  without  the 
completion  of  an  extensive  study.  Early  studies  concluded  that  lETMs  were  significantly 
superior  to  the  traditional  paper-based  technical  manuals  under  operationally  realistic  conditions. 
lETMs  solved  or  mitigated  many  of  the  problems  identified  in  the  previous  paragraph  as  follows: 

•  Weight  -  Standard  calculations  assume  that  a  CD  can  store  approximately  3,400  pages  of 
text,  tables  and  graphics.  This  is  about  20  pounds  of  paper-based  information.  Since  a  CD 
(with  the  jewel  case)  weighs  less  than  two  ounces,  the  AEGIS  Class  cruiser  could  reduce  its 
74,000  pounds  of  paper  weight  to  less  than  500  pounds  if  all  information  were  to  be  placed 
on  CDs.  While  some  weight  would  need  to  be  added  to  account  for  lETM  viewing  hardware, 
the  reduction  in  weight  for  mobile  units  would  in  select  instances  increase  maneuverability 
and  reduce  fuel  consumption. 

•  Volume  -  Approximately  1 ,850  cubic  feet  of  storage  space  is  needed  to  store  the  37  tons  of 
paper  aboard  an  AEGIS  Class  cruiser.  The  same  documentation  would  only  occupy  35  cubic 
feet  if  placed  entirely  on  CD.  Many  facilities,  which  now  receive  duplicate  copies  of  a  single 
technical  manual,  operate  in  a  networked  environment.  A  single  copy  of  an  lETM  on  CD, 
would  be  sufficient  for  the  initial  lETM  network  installation  and  would  serve  as  a  backup. 

•  Information  Access  -  At  a  minimum,  even  the  most  basic  (Class  I)  lETMs  provide  a  limited 
hyperlinking  capability  to  allow  the  user  to  point,  click,  and  quickly  access  desired 
information.  The  functionality  of  higher-order  classes  permits  word/phrase  search  capability, 
internal  cross-reference  links  and  links  to  other  material  (inventory,  training,  etc.).  Northwest 
Airlines,  using  a  prototype  system,  experienced  a  minimum  50  percent  reduction  in  airline 
mechanics’  time  spent  looking  for  the  appropriate  documents. 

•  Up-to-date  Information  -  Once  an  lETM  has  been  developed,  a  process  for  integrating  and 
distributing  updates  should  be  implemented.  The  electronic  “sticky  notes”  feature  of  many 
lETMs  can  be  used  as  an  interim  solution  between  updates.  These  notes  are  simply  folded 
into  the  source  file  and  delivered  as  a  complete  revision  on  a  periodic  basis.  More 
sophisticated  lETMs,  manuals,  which  may  also  include  a  “notes”  feature,  require  the  entire 
database  to  be  delivered.  A  method  known  as  “push  technology”  is  now  being  evaluated  for 
updating  Web-based  lETMs. 

2.3  Military  lETM  Studies 

The  Naval  Surface  Warfare  Center,  Carderock  Division  (NSWC-CD)  released  a  report  in 
October  1996  entitled  “Maintenance  and  Logistic  System  Support  Benefits  Resulting  from 
Introduction  of  lETM  Based  Technology.”  The  study  group  identified  clear  benefits  to 
employing  lETMs  onboard  operational  units.  Consider  the  following  evaluation  summaries  from 
Commanding  Officers  of  Navy  ships  after  their  personnel  performed  an  onboard  assessment  of 
the  Radio  Communication  Set  (RCS)  lETM: 
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CO.  USS  ANZIO 


•  “The  lETM  is  light  years  ahead  of  the  standard  Tech  Manuals  of  raster-scanned  pages  and 
has  become  a  critical  part  of  the  operation  and  maintenance  of  the  RCS.” 

•  “lETMs  are  an  information  multiplier.  With  lETM(s)  as  a  tool/coach,  junior  personnel  can 
perform  complex  technical  tasks  with  nearly  the  same  effectiveness  as  senior  techs.” 

•  “Utility  is  outstanding.  Techs  and  operators  are  using  lETMs  exclusively  because  of  speed 
and  ease  of  technical  access  to  data.” 

CO.  USS  SHILOH 

•  “RCS  lETM  program  is  outstanding.  It  works  and  has  greatly  enhanced  communication 
readiness  on  Shiloh.” 

•  “lETM  approach  should  be  applied  to  technical  documentation  for  other  AEGIS  ship  systems 
(e.g.,  CSOSS,  CSTOMS,  EOSS,  NSTM,  Interface  information,  etc.).” 

•  “Program  should  be  expanded  to  include  all  new  construction  CG/DDGs.” 

•  “This  system  is  a  winner  and  the  sailors  love  it.” 

Overall,  the  results  of  limited  introduction  of  the  RCS  lETM  into  the  Navy  are  summarized  as 
follows: 

•  Sailor  classroom  feedback:  Outstanding 

•  95  percent  rated  lETM  features  used  as  good  or  excellent 

•  93  percent  preferred  lETMs  to  equivalent  paper  technical  documentation 

•  Majority  cited  speed  and  ease  of  use  as  greatest  advantages 

As  a  point  of  reference,  the  RCS  lETM  was  a  more  capable  (Class  IV)  system.  Generally 
speaking,  the  benefits  obtained  from  lower-class  lETMs  are  space/weight  savings,  quicker 
access/hyperlinked  access  to  desired  information,  and  lower  distribution  costs.  When  lETMs  are 
linked  to  the  entire  enterprise  (e.g.,  training,  supply,  maintenance  reporting  systems),  other 
benefits  will  also  be  realized. 

The  NSWC-CD  report  highlighted  a  number  of  logistical  areas  where  real  cost  savings  could  be 
realized  through  deployment  of  lETMs.  The  remainder  of  this  chapter  discusses  the  findings  of 
this  report. 
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2.4  Maintenance  Improvements 

The  corrective  maintenance  process  begins  with  discovering  and  reporting  a  system  malfunction. 
It  proceeds  to  completion  when  the  unit  is  brought  back  online.  In  between,  various  procedures 
are  conducted  to  verify  the  fault,  identify  and  repair  the  faulty  component,  and  operationally 
check  out  the  performance  of  the  equipment.  Every  step  of  the  process  is  vulnerable  to  human 
error.  Automation  of  the  corrective  maintenance  process,  through  the  introduction  of  lETM 
technology,  can  greatly  increase  operational  availability  and  reduce  the  logistic  support  burden 
throughout  DoD. 

Below  are  a  few  of  the  areas  where  maintenance  process  improvements  can  be  realized  with 
increased  use  of  lETMs: 

•  Reduced  false  alarms 

•  Increased  percentage  of  successful  fault  isolation 

•  Reduced  fault  isolation  times 

•  Reduced  maintenance  time 

•  Reductions  in  false  removal  rates 

•  Greater  effectiveness  of  inexperienced  technician 

•  Improved  personnel  and  equipment  safety 

•  Reduction  in  turn-around  time  for  reporting  and  correcting  technical  manual 
discrepancies 

•  Reduction  in  technician  time  spent  completing  maintenance  reporting  forms 

2.5  Fault  Reporting  and  Fault  Isolation  Improvement 
2.5.1  Reduction  in  False  Alarm  Rate 

Characteristically,  a  fraction  of  all  fault  reports  consists  of  false  alarms.  If  a  maintenance 
technician  cannot  verify  a  fault,  the  problem  is  reported  as  a  CND  (Cannot  Duplicate)  or  similar 
designation.  An  aircraft,  for  example,  will  be  removed  from  operational  service  for  further  tests 
or  will  be  tentatively  returned  to  service.  This  can  be  a  serious  matter  if  the  fault  really  exists. 
Tests  have  demonstrated  that  use  of  lETMs  greatly  reduces  such  occurrences.  The  Naval  Air 
Systems  Command  conducted  a  series  of  tests  during  the  Aircraft  Maintenance  Integrated 
Diagnostics  Demonstration  (AMIDD),  with  an  integrated  lETM  system  in  an  F/A-18  C/D 
squadron.  The  AMIDD  Project  Office  stated  that  in  going  from  paper  TMs  to  lETMs,  CNDs 
could  be  reduced  by  approximately  50  percent. 
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2.5.2  Increased  Fault  Isolation  Success  Rate 

When  a  technician  has  verified  that  a  reported  fault  exists,  the  technician  must  locate  the  faulty 
component  using  Built-in  Test  Equipment  (BITE)  information  or  an  operator's  statement  of  the 
mal^nction.  With  complex  systems,  fault  isolation  is  probably  the  most  difficult  step  in  any 
maintenance  sequence.  Paper-manual  fault-isolation  procedures  are  cumbersome  and  static 
(non-interactive).  Often,  possible  fault  sequences  cannot  be  covered  in  a  reasonable  period  of 
time.  (The  limitation  is  often  with  the  paper  medium  and  not  the  engineering  content.) 
Consequently,  the  process  of  troubleshooting,  based  on  step-by-step  sequence  through  a  fault 
tree,  can  end  in  failure.  In  such  a  case,  the  process  is  repeated,  or  the  whole  problem  is  referred 
to  a  higher  maintenance  level  (e.g.,  0-level  to  I-level).  A  field  test  using  the  AN/SPA-25D  radar 
repeater  showed  an  increase  in  the  fault  isolation  success  rate  from  64  percent  to  100%  for 
experienced  technicians  and  from  54  percent  to  100  percent  for  inexperienced  technicians.  Note 
that  in  this  instance,  inexperienced  technicians  became  as  proficient  as  experienced  technicians. 
In  a  similar  case,  an  F-14A  test  showed  an  improvement  from  42  percent  successful  fault 
isolation  with  conventional  technical  manuals  to  100  percent  successful  fault  isolation  with 
lETMs. 


2.5.3  Fault  Isolation  Time  Reduction 

The  time  required  for  fault  isolation  is  also  reduced  through  the  use  of  lETMs.  For  example. 
Navy  field  tests  on  the  AN/SPA-25D  showed  a  decrease  in  fault-isolation  time  of  24  percent  for 
various  inserted  faults  when  lETMs  were  used  in  the  corrective  maintenance  process.  Other  tests 
have  provided  similar  results.  The  Air  Force  reported  that  Integrated  Maintenance  Information 
System  (IMIS)  tests  on  the  F/A-18  aircraft  resulted  in  fault-isolation  time  reduction  by  37 
percent.  The  Naval  Personnel  Research  and  Development  Center  (NPRDC)  documented  a 
decrease  in  fault-isolation  time  of  56.8  percent  while  conducting  tests  on  a  set  of  communication 
equipment  lETMs.  The  magnitude  of  the  cited  improvements,  including  improved  performance 
of  less  experienced  technicians,  has  been  repeatedly  verified  in  independent  tests. 

The  fact  that  an  lETM  significantly  shortens  the  time  required  to  perform  troubleshooting  is  due 
largely  to  its  interactive  functions.  A  technician  enters  a  test  result  and  the  lETM  can 
automatically  and  immediately  advance  to  the  next  appropriate  test.  This  process  continues  until 
the  cause  of  the  problem  is  isolated.  Electronically  displayed  information-format  improvements 
contribute  to  the  effectiveness  of  the  lETMs.  For  example,  using  the  lETM,  text  and  relevant 
graphics  can  be  presented  in  a  side-by-side  format  to  save  the  technician  from  having  to  search 
for  locator  information.  In  paper  manuals,  the  text  is  frequently  not  co-located  with  relevant 
graphics,  forcing  the  technician  to  search  for  the  required  information.  Finally,  lETMs  provide 
"how  to"  instructions,  whereas  the  steps  in  paper  manuals  merely  state  "what  to  do"  —  assuming 
the  technician  knows  how. 

2.6  Maintenance  Procedure  Improvements 

2.6.1  Reduced  Maintenance  Time 
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After  troubleshooting  has  identified  the  cause  of  a  deficiency,  technicians  need  to  perform 
correction  tasks.  These  are  usually  repairs  (straighten  pins,  splice  wiring,  calibrate,  adjust),  or 
remove-and-replace  (R&R)  actions.  Hughes  Aircraft  conducted  an  investigation  of  the  Navy 
Technical  Information  Presentation  System  (NTIPS),  centering  on  the  benefits  of  replacing  paper 
manuals  with  lETMs. 

NTIPS  tests  on  the  AN/SPA-25D  system  showed  a  decrease  in  repair  time  for  both  experienced 
technicians  (by  16  to  28  percent)  and  inexperienced  technicians  (by  22  to  30  percent). 

2.6.2  Reduced  False  Removal  Rates 

Once  a  faulty  component  is  identified,  it  is  either  repaired  (when  the  maintenance  procedures  for 
the  system  so  indicate),  or  removed  and  replaced.  Removed  components  are  usually  forwarded 
from  an  0-level  maintenance  facility  to  an  I-level  Maintenance  Activity  (IMA)  for  evaluation. 
Typically,  a  large  fraction  of  removed  parts  have  been  found  not  to  be  defective,  indicating 
unnecessary  removals. 

The  USAF  F-16  tests  with  IMIS  (Integrated  Management  Information  Systems)  showed  a 
reduction  of  26  percent  in  false-removal  rates  by  specialists,  and  37  percent  by  non-specialists.  A 
briefing  on  the  results  of  the  AMIDD  tests  reported  a  reduction  in  false-removal  rates  of  60 
percent. 

2.7  Greater  Effectiveness  of  Inexperienced  Technicians  with  lETMs 

As  indicated  in  the  previous  paragraphs,  the  performance  of  inexperienced  technicians  using 
lETMs  has  shown  striking  improvement  relative  to  that  of  technicians  of  the  same  level  of 
experience  using  paper  TMs.  This  improvement  has  been  particularly  noticeable  in 
troubleshooting  success.  Early  F-14A  lETM  tests  revealed  inexperienced  technicians  using 
paper  TMs  were  unable  to  locate  a  fault  inserted  into  an  operational  F-14A.  When  an  lETM  was 
used,  all  of  the  technicians  tested  successfully  located  the  fault.  In  general,  inexperienced 
technicians  perform  on  a  level  equivalent  to  that  of  experienced  technicians  when  an  lETM  is 
utilized.  The  lETM  can  be  expected  to  compensate  in  some  measure  for  both  a  shorter  training 
program  and  less  experience  among  technicians. 

2.8  Improved  Personnel  and  Equipment  Safety 

TMs  include  numerous  WARNINGS  (which  point  out  situations  involving  danger  to  personnel), 
CAUTIONS  (which  identify  situations  involving  possible  damage  to  equipment),  and  NOTEs 
(pointing  out  possible  errors  in  procedure).  With  paper  manuals,  problems  resulting  from  a 
technician  ignoring  or  misunderstanding  these  instructions  are  not  uncommon.  In  an  lETM 
procedure,  the  technician  cannot  continue  without  explicitly  acknowledging  his/her  observation 
of  WARNINGS  and  CAUTIONs.  Moreover,  WARNINGS,  CAUTIONs,  and  NOTEs  are  more 
effectively  displayed,  via  popup  dialog  boxes  and/or  in  color,  to  the  technician  than  in  the  case  of 
paper  manuals.  "HELP,”  through  an  online  hypertext  system,  or  “coach,”  may  be  available  if 
he^he  does  not  understand  the  information  presented. 
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The  capability  of  lETMs  to  be  automatically  updated,  via  electronic  sticky  notes  or  e-mail, 
means  that  safety-related  messages  and  updates  will  appear  far  more  rapidly  in  the  electronic 
technical  data  package  than  in  paper  TMs. 

2.9  Reduction  in  Cycle  Time  for  Reporting  Technical  Manual  Discrepancies 

With  establishment  of  direct  interaction  of  an  on-board  maintenance  Local  Area  Network  (LAN) 
with  a  management  information  system,  response  time  for  the  submission  of  lETM  deficiencies 
in  technical  information  can  be  reduced  from  weeks  to  hours  by  the  use  of  direct  electronic- 
trouble  reporting.  The  user  in  many  cases  may  receive  a  same-day  response  to  verify  receipt  of 
his/her  trouble  report.  Corrections  involving  issues  related  to  personnel  or  ship  safety  can  be 
routed  to  the  responsible  activity  within  hours  of  receipt,  in  lieu  of  a  longer  period  required  to 
route  paper.  The  Naval  Sea  Systems  Command  (NAVSEA)  has  been  working  on  the  Technical 
Information  Deficiency  Evaluation  System  (TIDES)  to  achieve  this  goal. 

2.10  Reduction  in  Technician  Time  Required  for  Maintenance  Reporting 

As  a  part  of  each  maintenance  action,  a  technician  must  fill  out  a  standard  maintenance  report 
form,  which  differs  somewhat  between  services  and  for  different  types  of  systems.  Tests  based 
on  the  actual  conduct  of  the  specific  maintenance  action,  as  reflected  by  the  interaction  of  the 
technician  and  the  lETM,  have  shown  that  automation  of  this  process  can  substantially  reduce 
the  time  required  for  this  procedure.  Similarly,  ordering  a  required  part  can  be  accomplished 
quickly  on  an  lETM  display  of  IPB  information.  This  replaces  the  time-consuming  process  of 
locating  parts  data  in  a  paper  manual,  filling  out  a  form,  and  delivering  the  form  to  the  supply 
chain.  With  an  lETM,  parts  inventories  can  be  instantly  adjusted  as  a  result  of  each  parts- 
ordering  action.  The  Air  Force  has  shown  that  the  time  required  to  order  necessary  parts  can  be 
reduced  by  94%  using  lETMs. 

2.11  Features  of  lETMs  that  Improve  Maintenance 
2.11.1  Access  to  Technical  Information 

One  of  the  key  elements  involved  in  effective  troubleshooting  and  repairing  of  equipment  is 
having  immediate  multipath  access  to  all  the  needed  technical  information.  With  lETMs,  all  of 
the  required  information  can  be  at  the  technician's  fingertips.  For  example,  lETMs  can 
incorporate  maintenance  aids  such  as  a  Fault  Lookup  Mode.  When  the  maintainer  receives  a 
BITE  fault  code  for  a  piece  of  equipment,  he/she  can  access  the  lETM  and  enter  the  fault  code. 
The  lETM  will  then  lead  the  maintainer  immediately  into  the  troubleshooting  procedure  for  that 
fault  code,  and  send  him/her  directly  to  the  proper  corrective  maintenance  procedure  and  IPB 
(Illustrated  Parts  Breakdown)  to  enter  the  data  into  the  supply  system.  Sailors  using  the  AEGIS 
Radio  Communications  System  lETM  retrieved  information  up  to  four  times  faster  than  with  the 
paper  documentation  that  it  replaced. 
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2.11.2  Greater  Display  Effectiveness  Due  to  Multimedia  Technology 

The  interactive  visual  presentation  of  complex  procedures  by  using  animations,  video  clips, 
virtual  reality  technology,  and  expert  system  modules  can  provide  the  maintainer  with  improved 
comprehension  of  technical  information.  The  benefits  of  audio,  in  addition  to  visual  notification 
windows,  can  improve  the  delivery  of  WARNINGS,  CAUTIONs,  and  NOTEs  in  troubleshooting 
and  maintenance  procedures. 

2.11.3  Integration  of  lETMs  with  Other  Management  Information  Systems 

The  Navy  has  already  integrated  the  lETM  with  the  Advanced  Technical  Information  System 
(ATIS).  This  provides  the  maintainer  with  access  to  all  of  the  technical  documentation  normally 
stored  in  disparate  locations.  This  resource  includes  the  entire  ship's  library.  Ships  Service 
Manuals  (SSMs),  Engineering  Drawings,  Maintenance  Requirement  Cards  (MRCs),  and 
Standard  Operating  Procedures  (SOPs).  As  other  “islands  of  information”  come  online  within  the 
services,  integration,  through  middleware  applications,  will  become  a  priority.  Only  when  the 
information  systems  of  each  service  are  tied  into  a  DoD  wide  network,  will  the  benefits  of 
automation  (e.g.,  parts  ordering  from  a  centralized  DoD  facility)  be  fully  realized. 

2.12  Improvements  in  Life-cycle  Support 

Although  reliable  quantitative  estimates  are  as  yet  generally  unavailable,  it  is  clear  that  life-cycle 
costs  of  maintaining  lETMs  will  be  a  fraction  of  the  cost  required  to  maintain  conventional  paper 
manuals.  It  has  been  estimated  that  a  reduction  of  20%  in  ownership  costs  (life-cycle  support 
costs)  for  the  LM2500  Gas  Turbine  will  result  from  the  introduction  of  an  lETM  to  support  its 
training  and  Fleet  maintenance. 

An  evaluation  of  the  effectiveness  of  the  LM2500  Gas  Turbine  lETM  effort  carried  out  by  the 
NPRDC  stated: 


'The  elimination  of  seven  training  weeks  from  the  GSE  training  pipeline  and  three  training 
weeks  from  the  GSM  pipeline  results  in  a  reduction  in  student  training  costs  of  over  $1,900,000 
in  FY  95  and  FY  96.  The  cost  savings  in  avoiding  reproduction  of  the  paper-based  technical 
manuals  used  in  the  GSE/GSM  courses  were  estimated  at  $96,000  for  FY  96." 

2.12.1  Reduction  in  Time  and  Errors  for  Technical  Information  Update/Modification 

Correcting  and  updating  electronic  media  can  be  more  thoroughly  and  effectively  performed  by 
the  use  of  key  text-searching  capabilities.  Global  find  and  replace  actions  for  paper  legacy  data 
require  a  hit-or-miss  visual  scan  of  the  entire  paper-based  product,  often  resulting  in  failures  to 
correct  all  instances  of  the  desired  changes.  Significant  time  is  currently  spent  to  generate  and 
maintain  conventionally  based  paper  products.  This  includes  the  time  required  to  review  for 
potential  errors  in  technical  information  updates.  Automatic  referencing  of  the  electronically 
stored  tables  and  figures  ensures  absolute  and  correct  updates  to  numbering  changes  created  by 
revisions  to  the  source  material.  Electronic  media  also  enables  the  automatic  generation  of  the 
table  of  contents,  list  of  figures,  list  of  tables  and  indexes. 
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Changes  are  made  to  the  entire  lETM  at  once  instead  of  producing  a  separate  change  package  for 
each  stand-alone  paper  TM.  Changes  that  ripple  through  the  entire  set  of  manuals  could  be 
quickly  and  effectively  located  and  corrected  by  the  use  of  the  search  features  available  with 
electronic  media,  a  function  not  available  for  paper-based  products.  Advance  Change  Notices 
(ACNs)  can  be  delivered  as  annotated  files  to  supplement  the  lETM,  thus  reducing  ACN 
printing,  shipping,  and  storage  costs. 


2.12.2  Reduction  in  Costs  of  Technical  Information  Printing  and  Publishing 

Printing  costs  can  be  eliminated  by  the  replacement  of  paper-based  manuals  with  electronically 
generated  media.  The  cost  of  mastering  and  reproducing  a  CD  is  less  than  the  setup  costs  of 
reproducing  a  paper-based  set  of  manuals.  The  cost  of  procuring  and  storing  binders  can  also  be 
eliminated. 

2.12.3  Reduction  in  Storage  Space  Required  for  Technical  Information 

Storage  space  requirements  can  be  substantially  reduced  with  the  elimination  of  paper  technical 
manuals.  This  space  requirement  can  be  reduced  to  a  single  filing  cabinet  for  the  storage  of  the 
equivalent  magnetic  material.  It  has  always  been  anticipated  that  lETM  display  equipment  would 
not  be  purchased  solely  to  view  lETMs.  Thus,  lETMs  may  take  advantage  of  existing  computer 
display  systems. 

2.12.4  Reduction  in  Shipping  Costs 

Shipping  costs  can  be  reduced  for  conventional  shipment  of  routine  initial  distribution  material 
and  routine  updates.  The  cost  of  distributing  emergent  changes  to  paper  manuals  will  be  reduced 
to  a  few  pounds  of  the  electronic  equivalent.  This  expense  could  drop  further  as  changes/updates 
are  made  using  satellite  links. 

2.12.5  Automation  and  Integration  of  Logistic  Support  Technical  Information 

The  use  of  automated  techniques  to  create,  manage,  deliver  and  update  technical  information 
documentation  via  an  easily  revisable  database  across  hardware  and  software  neutral  platforms 
will  greatly  reduce  the  life-cycle  costs  of  technical  information  and  improve  the  quantity  and 
functional  integration  of  information  for  end-user  use.  The  lETM  and  its  associated  database 
will  be  the  repository  for  all  deliverable  technical  information  relating  to  the  documented  system; 
information  which  can  be  extracted  easily  and  quickly. 

An  lETM  production  process  should  electronically  integrate  those  areas  of  the  logistics 
discipline  that  support  the  development  and  organization  of  technical  information  for  system 
operation,  maintenance  and  training.  In  addition  to  training,  these  functions  include  logistics 
support  analysis,  human  factor  engineering,  reliability/maintainability  and  maintenance  planning. 
In  the  process  of  forming  an  integrated  end-user  product,  the  lETM  will  make  maximum  use  of 
existing  electronic  data  to  lower  cost,  maximize  consistency  and  provide  a  medium  for  user 
inputs. 
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2.12.6  Supply  Support 


Implementation  of  DETMs  reduces  the  weight  and  storage  requirements  associated  with  paper- 
based  manuals.  As  a  result,  weapons  platforms  are  able  to  carry  additional  mission-critical 
equipment  or  stores.  Supply  support  costs  will  be  decreased  because  there  will  be  less  mis- 
ordering  of  parts.  This  will  be  a  direct  result  of  improved  fault  localization/identification  via  the 
expert-system  troubleshooting  routines  available  in  lETM  technology.  This  translates  directly 
into  reduced  weapon-system  maintenance  costs  and  decreased  time  to  repair. 
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CHAPTER  3 
CLASSES  OF  lETMS 


3.1  lETM  Definitions 

As  lETMs  began  to  proliferate,  so  did  the  methods  for  converting  and  presenting  digital  data. 
While  careful  not  to  inhibit  innovation,  the  military  did  not  want  contractor  proprietary  solutions 
either.  NSWC,  Carderock  Division,  released  a  document  titled  “DoD  Classes  of  Electronic 
Technical  Manuals,”  which  addressed  five  classes  (Class  I  through  Class  V)  of  lETMs  based  on 
the  source  data  format  of  the  lETM  and  its  functionality. 

The  Classes  are  defined  in  fairly  general  terms  that  necessarily  overlap.  They  facilitate 
discussion  of  options  and  differences,  but  they  are  insufficient  to  serve  as  a  basis  for  contractual 
use  (e.g.,  direct  the  contractor  to  prepare  a  “Class  ni”  manual).  The  Statement  of  Work  (SOW) 
or  Technical  Manual  Contract  Requirements  (TMCR)  should  specify  exact  functionality 
requirements  without  referring  to  this  set  of  definitions.  The  structure  of  each  class  is  illustrated 
in  Figure  3-1.  Table  3-1,  found  at  the  end  of  this  chapter,  summarizes  the  key  points  of  each 
class  of  EETM,  for  ready  reference. 

3.1.1  Class  I  -  Electronically  Indexed  Page  Images 

These  lETMs  include  digital  page  images  obtained  from  raster  scanning,  using  the  Navy 
Implementation  of  Raster  Scanning/Navy  Image  File  Format  (NIRS/NIFF).  They  are 
intelligently  indexed,  based  on  the  front  matter  (i.e.,  table  of  contents,  list  of  figures/fold- 
outs/tables  etc.)  and  rear  index  using  MIL-M-29532.  This  indexing  allows  the  user  to  select  a 
topic  from  front  matter  and  have  the  corresponding  raster  page,  from  the  body  of  the  TM, 
automatically  displayed  or  to  create  an  automatic  collation  of  page  changes.  Page  orientation  is 
retained  and  can  be  directly  printed. 

3.1.2  Class  II  -  Electronic  Scrolling  Documents 

Most  of  these  ASCII-based  EETMs  conform  to  Standard  Generalized  Markup  Language 
(SGML),  per  MIL-PRF-28001,  and  link  front  matter  to  corresponding  material  in  the  body  of  the 
TM.  (Refer  to  Appendix  A  for  additional  information  relating  to  SGML).  They  may  have 
additional  links  to  cross-references,  tables,  figures,  etc.  and  to  voice,  video,  expert  systems,  or 
other  special  external  applications.  They  generally  have  word  search  and  bookmark  capabilities, 
electronic  sticky  notes,  and  may  contain  raster  or  vector  graphics.  The  linked  manual  can  be 
viewed  electronically  or  be  printed  in  compliance  with  existing  military  style  and  format 
specifications.  While  MIL-PRF-28001  is  the  preferred  format  at  this  time,  other  SGML  formats 
(e.g.,  HyperText  Markup  Language,  HTML)  are  emerging  and  provide  similar  benefits.  A 
second  format,  Adobe’s  Portable  Document  Format,  PDF,  is  also  being  used  for  basic 
conversions.  As  discussed  in  detail  in  Appendix  A,  PDF  is  based  on  Adobe’s  Postscript  printer 
language  and  allows  Class  II  interactivity.  However,  the  PDF  file  cannot  currently  be  edited. 
Consequently,  if  the  Government  chooses  to  maintain  the  TM  data  through  PDF  files,  it  must 
first  own  or  have  access  to  the  publishing  system  that  generated  those  files  before  it  can  ensure 
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Figure  3-1.  Graphical  Representation  of  IBTM  Classes 


that  data  maintenance  and  update  responsibilities  can  be  transferred  between  technical  manual 
maintenance  activities.  Disagreements  exist  both  within  and  between  the  services,  about 
classifying  PDF  as  a  Class  I  or  Class  n  document. 

3.1.3  Class  III  -  Linearly  Structured  lETMs 

These  lETMs  have  enhanced  functionality  over  Class  n.  They  may  have  MIL-PRF-28001  or 
MIL-PRF-87269  SGML  tags  applied  to  the  ASCII  text  to  allow  user  iriteraction  through  “view 
packages.”  View  package  requirements  can  be  developed  to  emphasize  fimctional  subjects,  such 
as  training,  maintenance,  and  system  overview.  Being  linearly  stmctured.  Class  III  lETM  files 
can  be  used  to  print  hard-copy  TMs.  But  while  all  of  the  data  will  appear  in  the  proper  sequence, 
the  printed  copy  will  not  necessarily  be  in  the  same  format  as  the  traditional  "MIL  SPEC" 
manual.  Class  HI  lETMs  can  include  optional  linkages,  such  as  voice,  video,  expert  systems  or 
special  applications.  Caution  and  planning  are  required,  however,  if  a  single  database  is  intended 
to  produce  the  BETM  and  publish  the  hard-copy  TM. 

3.1.4  Class  IV  -  Hierarchically  Structured  lETMs 

Class  rv  is  a  complete  departure  from  the  previous  classes  in  which  data  is  structured  to  support 
a  classical  publishing  environment  based  upon  sentences,  paragraphs,  chapters,  pages,  etc.  Class 
rv  data  is  created  or  re-authored  and  then  rebuilt  into  a  database.  It  is  then  managed  as 
hierarchical  objects  within  a  database.  In  acquisition.  Class  IV  technical  data  is  built  into  a 
structured  database,  using  Logistic  Support  Analysis  (LSA)  disciplines  and  formats  to  create  the 


database.  Data  is  only  created  once  with  no  duplication.  For  legacy  TMs,  two  types  of  duplicate 
data  are  found: 

•  Identical  data  is  exactly  repeated,  each  time  it  is  found.  Examples  include  WARNINGS, 
CAUTIONS,  NOTES,  common  procedural  steps,  graphics,  etc. 

•  Redundant  data  sets  convey  the  same  information,  but  cannot  be  substituted  for  one  another. 
Examples  include  paragraphs  containing  essentially  the  same  steps,  but  they  must  be 
managed  as  individual  data  sets,  because  the  words  within  each  paragraph  provide  a  different 
context  for  each  occurrence  (e.g.,  refer  to  different  figures  or  different  preceding  paragraphs). 

With  Class  HI,  identical  data  can  be  eliminated.  Because  re-authoring  is  avoided  to  minimize 
cost  or  to  preserve  the  ability  to  print  hard-copy,  much  redundancy  remains.  For  conversion  of 
legacy  data  to  Class  IV,  data  is  re-authored  to  remove  its  formatting  and  to  rebuild  the  data  into  a 
structured  database.  Paragraphs  or  information  can  be  decomposed  to  simple  statements  that 
approximate  Logistic  Support  Analysis  Record  (LSAR)  type  of  entries  at  the  step  level.  As  the 
new  structure  eliminates  previous  need  for  duplicate  data,  the  redundant  data  also  is  eliminated. 
The  application  (view)  program  then  provides  the  necessary  context  and  transition.  The  total 
amount  of  data  being  stored  and  managed  is  significantly  reduced,  and  multiple  updates  within 
the  lETM  are  eliminated.  Other  SGML  based  databases  found  in  Class  II  and  III  lETMs  also 
have  the  ability  to  store  data  once  and  apply  it  many  times.  They,  however,  can  only  share  these 
information  objects  within  a  single  lETM. 

Data  linkages  in  Classes  I  through  III  rely  on  application  programs  such  as  scripting  or 
hyperlinking  to  define  the  linkages  between  data.  Their  Data  Base  Management  System 
(DBMS)  manages  the  objects,  if  applicable,  but  not  the  structure.  For  Class  IV,  building  a 
hierarchical  database  structure  (typically  following  an  LSAR)  provides  the  inherent  logic  and  the 
linkages  among  and  between  data.  This  principle  greatly  simplifies  the  processing  of  change 
data  and  the  use  of  application  programs.  lETM  data  modules  are  structured  in  conformance 
with  MIL-PRF-87269  and  may  be  represented  as  SGML-tagged  files.  All  item  links  are  built 
into  the  structure  of  the  DBMS.  The  availability  of  modules  (e.g.,  figures,  text,  tables,  video, 
voice  clips)  enables  the  user  to  access  information  in  a  highly  interactive  manner  and  from  a 
variety  of  paths.  The  text  is  created  or  edited  to  have  the  same  "look  and  feel"  as  the  steps  in 
LSAR  entries.  lETMs  have  user-interfaces  developed  in  accordance  with  MIL-PRF-87268  and 
provide  "frame-,"  rather  than  "page-"  oriented  displays.  The  Class  IV  lETM  can  prompt  the  user 
or  may  directly  receive  fault  code  information  from  which  the  EETM  software  determines  the 
appropriate  path  to  display  through  the  database.  As  its  contents  are  contained  in  a  hierarchically 
structured  database,  a  Class  IV  lETM  cannot  be  printed  as  a  unit  for  distribution  in  hard-copy 
form. 

A  third  primary  difference  between  Class  IV  and  the  first  three  lETM  classes  is  that  the  Class  IV 
product  is  not  bound  by  a  predetermined  sequence  of  presentation.  While  the  sequencing  of  data 
may  be  different  for  different  view  packages.  Class  II  and  III  would  have  to  establish  the 
sequenced  data  files  for  each  view  package;  Class  IV  would  create  it  directly.  Class  IV  lETMs 
(and  Class  V  lETMs  that  use  Class  IVs  as  a  base)  have  the  ability  to  naturally  apply  precondition 
and  applicability  statements  within  the  lETM  database  and  to  "branch  on  condition  found."  The 
program  analyzes  each  condition  and  brings  in  the  necessary  data.  This  process  continues 
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through  to  a  logical  conclusion.  By  using  these  features,  a  Class  IV  lETM  can  display  only  "user 
specific"  data  from  the  database  and  can  tailor  presentations  based  on  several  input  criteria.  For 
example,  it  may  only  present  certain  maintenance  choices  to  a  trainee,  but  present  additional 
choices  to  a  journeyman  working  with  the  same  equipment  configuration  and  fault  indicators. 
Class  IV  lETMs  can  share  data  sets  among  users,  thereby  making  data  maintenance  even  more 
efficient. 

Program  Offices  may  encounter  contractors  with  significant  investments  in  legacy  publishing 
systems,  legacy  lETM  software  tools,  and  lack  of  work  force  training  in  or  understanding  of 
Class  IV  production  processes.  These  factors  tend  to  weigh  lETM  recommendations  away  from 
Class  rV  functionality  and  toward  the  "status  quo."  The  persistent  comparison  of  sunk  costs,  in 
existing  systems  with  investments  needed  to  execute  new  technology,  generally  fails  to  consider 
all  costs  involved  in  product  creation  and  review,  or  to  consider  the  potential  savings  to  be 
achieved  throughout  the  life  cycle.  Nonetheless,  the  acquisition  of  SGML-tagged  "linear 
databases"  can  provide  many  end-user  features  and  some  of  the  advantages  found  in  maintaining 
object-oriented  databases  through  different  strategies  of  use.  Whether  object  oriented  or  linear, 
SGML- tagged  databases  support  the  longer-term  goal  of  the  CALS  data  integration  philosophy. 

3.1.5  Class  V  -  Integrated  Database  lETMs 

The  Class  V  lETM  combines  the  functionality  and  capabilities  of  an  expert  system  with  a 
technical  database.  This  allows  the  user  to  perform  tasks  more  quickly  and  accurately.  The 
DSMC  lETM  Guide  does  not  address  the  requirements  of  expert  systems  or  the  efforts  needed  to 
achieve  the  full  integration  of  a  multi-functional  Class  V  system.  It  does  address  the  lETM 
component  of  a  Class  V  manual  and  the  interface  to  an  expert  system.  Class  V  lETMs  allow  the 
subject  matter  experts  (SMEs),  in  all  areas  (e.g.,  troubleshooting,  fault  isolation,  accomplishing 
repairs,  establishing  alternate  repair  paths),  to  bring  their  knowledge  to  the  maintenance  unit  and 
apply  it  in  a  specific  situation.  The  system  and  equipment  diagnostic  programs  can  "talk" 
directly  to  the  user  through  the  lETM;  relatively  unskilled  technicians  can  be  led  through 
complex  procedures.  Seldom-used  processes  and  procedures  (e.g.,  annual  inspections)  can  be 
properly  planned  and  executed  without  significant  research.  Programs  will  also  typically  analyze 
the  data  received  and  add  it  to  the  knowledge  base  to  allow  the  software  to  "learn"  and  apply  the 
knowledge  to  future  analytical  processes. 
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CHAPTER  4 

ACQUISITION  OF  lETMS 


4.1  Introduction 

The  general  philosophy  of  lETM  acquisition  is  to  procure,  as  a  minimum,  a  Class  II  lETM  in  a 
format  such  as  SGML  or  Indexed  PDF.  (Refer  to  Appendix  A  for  detailed  information  about 
SGML  and  PDF.)  The  preferred  option  is  to  procure  standard  SGML-tagged  IFTM  data  that  are 
optimally  stmctured  to  create  survivable  data  in  revisable  and  economically  maintained 
databases  by  sharing  common  objects.  This  philosophy  is  a  key  element  in  the  migration  toward 
the  DoD’s  Integrated  Data  Environment  (IDE).  The  IDE  is  a  dynamic  data  environment  in 
which  all  users  draw  from  a  common  virtual  database  that  contains  data  maintained  by  an 
unlimited  number  of  Government  or  commercial  service  providers.  A  shared  information 
environment,  providing  immediate  access  to  digital  data,  supports  the  IDE.  An  lETM  may  also 
be  procured  as  a  logistic  support  product  under  a  major  weapon  system  or  equipment  buy  —  as  a 
separate  item  under  its  own  contract  to  support  new  equipment,  or  as  a  conversion. 


4.2  lETM  Acquisition  Process  Phases 


Figure  4-1  shows  the  general  phases  involved  in  the  lETM  acquisition  process. 


Develop  the  \ 
Government  I_ 
Concept  of  1 
Operations  1 


Figure  4-1.  lETM  Acquisition  Phases 

Criteria  for  the  digital  data  infrastructure  and  implementation  strategy  of  an  acquisition  program 
are  included  in  the  Government  Concept  of  Operations  (GCO).  This  document  is  a  necessary 
precursor  for  the  subsequent  phases  of  lETM  development.  Both  the  GCO  and  the  CONOPS 
(referred  to  below)  are  presented  in  detail  in  the  next  chapter. 

4.2.1  Phase  1:  Develop  an  lETM  Concept  of  Operations  (CONOPS) 

Chapter  5  discusses  the  lETM  CONOPS  in  detail.  The  document  provides  potential  offerors 
with  anticipated  lETM  support  requirements  of  the  proposed  system.  Users  and  the  issuing 
program  can  evaluate  the  proposed  lETM  solutions  against  the  support  requirements.  The 
CONOPS  provides  a  common  language,  set  of  assumptions,  and  point-of-departure  for  all 
Government  and  contractor  participants  in  the  process.  It  assists  the  program  in  ensuring  that 
needed  lETM  resources  are  in  place,  or  that  deficiencies  are  identified. 

Even  with  new  acquisitions,  much  of  the  technical  data  supporting  the  system  already  exists. 
The  program  decision  to  convert  this  data  (usually  to  a  standard  digital  format)  involves  a 
commitment  of  resources  to  accomplish  one  or  more  objectives  to  reduce  costs  and  improve 
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availability,  productivity  and  quality.  However,  each  of  the  Services  is  either  involved  in,  or  has 
completed  major  conversion  efforts,  that  have  involved  digitization  of  existing  TMs.  Many  of 
these  are  Class  II  lETMs  in  the  form  of  Indexed  PDF  files  or  linearly-structured  SGML  files. 
Prior  to  deciding  to  convert  data,  the  Program  Manager  needs  to  determine  whether  the  data  has 
already  been  converted  as  part  of  these  digitization  efforts.  The  decision  on  the  type  of  lETM  to 
select  is  critical.  Selection  impacts  cost  of  conversion;  available  functionality  ability  to  maintain 
and  update  data;  ability  to  interface  and  interact  with  other  data  files;  and  the  ability,  cost,  and 
effort  to  migrate  in  the  future  to  newer  technology.  A  functionality  decision  model  is  presented 
in  Figure  5-2  to  assist  the  Program  Manager  in  selecting  the  best  conversion  model  for  his  or  her 
program.  Development  of  an  lETM  CONOPS  is  a  critical  first  step  in  establishing  the  conditions 
within,  and  under  which,  the  lETM  will  be  expected  to  function.  The  act  of  preparing  the 
CONOPS  should  raise  and  clarify  issues  and  establish  parameters.  It  is  important  to  document 
the  conditions  and  assumptions  used  to  make  the  lETM  selection  decision  and  to  help  formulate 
an  implementation  strategy. 

4.2.2  Phase  2:  Develop  Procurement  Package 

The  lETM  procurement  process  varies  between  Services.  However,  there  is  agreement  that  an 
lETM  CONOPS  must  be  developed  prior  to  solicitation  to  ensure  programs  have  properly 
planned  for  lETM  definition,  implementation,  and  ongoing  maintenance.  Upon  development  of 
a  program-specific  lETM  CONOPS,  the  Program  Office  will  follow  procurement  guidance  for 
its  service. 

4.2.2. 1  Sample  List  of  lETM  Deliverables 

The  list  of  deliverables  will  vary  depending  on  the  Class  of  lETM  being  acquired.  The  following 
is  provided  as  guidance  only,  and  is  not  intended  to  be  a  complete  or  approved  list: 

a.  Technical  Manual  Schedules  and  Status  Reports.  In-Process  Reviews  (IPRs)  should  be 
held  at  the  30,  75,  and  100  percent  completion  milestones  to  ensure  all  parties  have  a 
common  understanding  of  the  final  product. 

b.  Outline  Book  Plan  or  equivalent  (will  apply  to  either  the  hard-copy  TM  or  lETM  and 
defines  the  content  and  the  structure  of  the  TM). 

c.  Quality  Assurance  Program  Plan. 

d.  Software  Development  Plan.  This  plan  should  specify  all  software,  including  the  utilities 
procured  or  developed  to  convert,  develop,  test  or  verify  the  lETM  being  delivered. 
Examples  of  software  include  conversion  filters,  Java  applets,  or  ActiveX  controls  that 
increase  lETM  functionality  -  and  helper  applications  that  may  connect  the  lETM  to 
training  modules. 

e.  The  DTD  (as  accepted)  and  its  final  SGML  tagged  file,  including: 

—I  Graphic  images  in  MIL-PRF-28002  Raster 

-  or  - 

—I  Graphic  images  in  conformance  with  MIL-PRF-28000 IGES 
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-  or  - 

^  MIL-PRF-28003  Computer  Graphic  Metafile  (CGM)  series  of  performance 
specifications  (note:  audio,  video,  Expert  Systems,  and  other  externally-linked  files 
used  within  the  Class  Hin  lETM,  or  these  same  file  types  found  within  Class  IV  or  V 
lETMs,  are  delivered  in  the  runtime  version  of  the  lETM,  as  noted  in  item  (h)  below). 

f.  Any  graphics  that  exist  in  vector  format  (vendor  format). 

g.  Source  publishing  system  file  (vendor  format)  if  other  than  that  as  described  in  item  (e) 
above.  This  could  be  a  Microsoft  Word,  Interleaf  or  PageMaker  file. 

h.  Runtime  version  of  the  lETM.  The  file  that  has  been  processed  through  the  lETM 
application  software  that  would  reside  on  media  to  be  viewed  by  the  user.  This  is  to 
include  all  linked  files  in  their  compiled  runtime  format.  This  deliverable  is  not  required 
if  the  runtime  version  is  the  same  SGML  used  as  described  in  item  (e). 

i.  CD  in  accordance  with  the  SOW. 

j.  Hard-copy  fold-outs  bound  in  a  Supplemental  Manual  (if  required). 

k.  Audio  and  video  materials  in  mutually  accepted  formats  and  media.  Popular  file  formats 
for  video  are  .AVI  and  .MOV;  animation  files  are  typically  .ELI  or  .FLC;  audio  files  are 
either  .WAV  or  .MID. 

l.  A  PDF  file  (only  for  those  lETMs  that  are  able  to  provide  hard-copy  products  for 
distribution). 

m.  Contractor  EETM  cost  data. 

n.  Configuration  Management  Plan  for  the  software  and/or  the  data,  as  necessary. 

o.  Software  Licensing  Costs  (for  distribution  in  the  user  environment). 

4.2.3  Phase  3:  Distribute  Procurement  Package  and  Evaluate  Contractor  Response 

Figure  4-2,  the  lETM  Acquisition  Process  Model,  illustrates  the  process  of  distributing  an  RFP 
and  evaluating  contractors’  lETM  proposals.  The  figure  also  illustrates  what  the  Government 
and  contractor  must  provide  in  the  acquisition  of  EETMs. 

The  lETM  Acquisition  Process  Model  below  contains  two  acquisition  process  scenarios.  Steps  1 
through  6  plus  16  and  17  identify  the  process  of  acquiring  an  lETM  only.  Steps  1  through  17 
identify  the  overall  lETM  acquisition  process  when  it  is  included  as  part  of  a  larger  system 
procurement. 

Step  1:  An  lETM  CONOPS  is  developed  by  conducting  a  data  call  in  accordance  with  DoD 

5010.12M  during  the  acquisition  planning  process.  The  data  call  is  used  to  gather  and 
define  the  lETM  requirements  from  the  appropriate  Logistic  Managers.  Note  that  the 
lETM  CONOPS  will  include  a  list  (including  the  scope)  of  all  relevant  software 
licensed  for  use  by  the  program.  It  will  also  require  that  the  contractor  stipulates  the 
software  packages  selected  and  the  anticipated  total  costs,  including  procurement  of 
additional  licenses  for  Government  technical  management,  reviewing  activities,  and 
users.  Note  also  that  lETM  requirements  are  a  small  portion  of  the  total  system 
Request  for  Proposal  (RFP)  (refer  to  Chapter  5  for  more  information  on  lETM 
CONOPS.) 

Step  2:  The  RFP  and  lETM  CONOPS  are  released  to  bidders. 
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Figure  4-2.  lETM  Acquisition  Process  Model 

Step  3:  Contractors'  proposals  are  received  and  evaluated  against  the  lETM  requirements. 

Step  4:  If  a  contractor’s  proposal  meets  all  lETM  functional  requirements,  determine  whether 

the  lETM  development  costs  are  acceptable. 

Step  5:  If  proposed  lETM  costs  are  acceptable,  determine  whether  the  contractor  has 

committed  to  using  lETM  software  that  is  currently  licensed  to  the  program.  The 
contractor  may  select  lETM  development  software  currently  licensed  by  the  program 
or  by  a  specific  Service.  If  not,  the  contractor  shall  determine  and  acknowledge  the 
costs  to  the  program  to  obtain  appropriate  licenses  for  the  contractor’s  selected  lETM 
software.  This  should  specify  costs  for  acquisition  and  life-cycle  use  by  users 
identified  in  the  lETM  CONOPS. 

Step  6;  Acquire  the  lETM. 

Step?:  The  program  must  evaluate  whether  the  contractor  satisfies  minimum  hardware 

system  requirements  prior  to  proceeding  further  within  these  steps. 

Step  8:  If  the  contractor  does  not  satisfy  proposed  system  requirements,  note  this 

appropriately  and  evaluate  the  next  proposal. 
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Step  9:  If  the  contractor  does  not  satisfy  lETM  requirements,  but  does  meet  system 

requirements,  the  program  may  consider  whether  lETM  requirements  are  reasonable 
and  justified  -  or  warrant  modification. 

Step  10:  If  the  lETM  requirements  are  to  be  changed,  modify  the  RFP  to  incorporate  the  new 
lETM  requirements  with  a  modified  CONOPS  and  distribute  to  the  bidders. 

Step  11;  If  negotiations  fail  to  identify  an  acceptable  lETM  solution,  the  program  can  decide  to 
acquire  only  the  technical  content  in  a  non-IETM  format. 

Step  12:  If  the  lETM  requirements  are  not  met  and  “technical  content  only”  is  not  desired, 
resolve  any  differences  through  negotiations. 

Step  13:  If  in-house  or  Service  Bureau  conversion  of  content  into  the  required  lETM  is  not 
desired,  the  contractor  proposed  lETM  should  be  acquired. 

Step  14:  The  program  must  delete  the  lETM  runtime  and  possibly  modify  the  other 
deliverables.  If  these  delivery  requirements  are  dropped,  the  contractor  will  be 
responsible  for  developing  and  delivering  the  technical  content  and  providing  the 
source  and  SGML  files,  but  not  developing  the  lETM  end  product. 

Step  15:  Once  the  content  is  acquired  by  the  program,  it  can  be  converted  (in-house  or  by 
Service  Bureaus)  into  an  lETM  having  the  required  functionality.  SGML  should  be 
the  data  format  in  which  the  content  is  received.  If  not,  both  program  and  contractor 
should  mutually  agree  to  the  format. 

Step  16:  Determine  whether  the  lETM  software  licensing  costs  are  acceptable,  and  whether  the 
software  contractor’s  proposal  meets  program  needs  or  provides  significant  features 
beyond  those  lETM  tools  currently  in  use;  endorse  the  request  to  procure  the  lETM 
software. 

Step  17:  Acquire  lETM  and  lETM  software  license.  Acknowledge  new  lETM  software 
licensing  with  appropriate  Licensing  Coordinator  as  identified  in  Appendices  D,  E,  F 
or  G.  The  central  tracking  of  the  various  lETM  software  packages  used  throughout 
the  Service  can  assist  in  achieving  economies  of  scale  with  lETM  vendors  as  well  as 
helping  identify  what  lETM  software  may  be  available  to  the  program  at  no  charge. 

4.3  Phase  4:  Acceptance  and  Testing  of  lETM  Products 

The  TMCR  describes  the  QA  responsibilities  of  the  acquiring  program  and  of  the  contractor 
preparing  the  lETM.  Included  in  the  TMCR  are  the  detailed  descriptions  of  the  QA  products  and 
processes  to  be  performed  in  developing  and  accepting  an  lETM  deliverable.  Verify  that  the 
contractor  has  met  all  of  the  lETM  functionality  requirements  through  IPRs  up  to  and  including 
the  final  deliverable.  Representatives  from  the  user  community  (sailors,  mechanics,  technicians, 
subject  matter  experts)  should  be  invited  to  review  the  product.  Engaging  the  user  throughout  the 
lETM  development  process  provides  ample  time  for  lETM  product  improvement. 
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CHAPTER  5 

PRE-IETM  DEVELOPMENT  ISSUES 

5.1  Introduction 

Today’s  PMs  face  a  dizzying  array  of  issues  when  undertaking  an  lETM  development  program. 
Fortunately,  processes  exist  which  can  assist  the  PM  in  determining  the  appropriate 
characteristics  for  the  Program's  lETMs.  Two  major  processes  (and  resulting  products),  the 
Government  Concept  of  Operations  (GCO)  and  the  lETM  Concept  of  Operations  (CONOPS), 
are  addressed  in  this  chapter. 

5.2  GCO  Development  Process 

The  Defense  Acquisition  University  has  developed  a  GCO  template,  the  GCO  Generator,  which 
is  downloadable  at  http;//www.acq.osd.mil/log/lro/toolkit/gco/gcointro.html,  to  provide  a  step- 
by-step  tool  that  assists  managers  in  selecting  digital  data  for  their  defense  systems.  The  GCO  is 
a  Government  document  used  to  provide  information  to  potential  offerors  about  the  Government 
infrastructure  and  Integrated  Data  Environment  (IDE)  implementation  strategy  for  defense 
systems. 

The  GCO  planning  process  should  start  as  early  as  possible  in  the  acquisition  process.  This 
Government  document  is  prepared  during  the  acquisition  planning  stage  for  each  procurement. 
Development  of  a  GCO  will  help  ensure  that  the  Government  can  access  or  receive,  via  the  IDE, 
the  correct  version  and  formats  of  digital  data  products  needed  to  acquire  and  support  a  defense 
system. 

The  GCO  can  assist  the  Program  Manager  in  determining: 

a.  Hardware  and  software  systems  the  Government  has,  or  is  developing,  to  manage  and  use 
the  data. 

b.  Data  users,  types  of  data,  frequency  of  use,  and  timeliness  of  data  access  or  delivery  to 
each  user. 

c.  Data  use  and  the  review/approval  processes  to  support  life-cycle  functions. 

d.  User  locations  and  their  primary  functions  in  support  of  the  defense  system. 

e.  Data  interchange  requirements  including  format,  media,  applicable  standards,  and 
existing  telecommunications  capabilities. 

f.  Access  authorizations  and  restrictions. 

g.  Data  acceptance  requirements  including  data  format,  content,  and  the  Government 
processes  for  accepting  product  data,  processable  data,  or  Contractor  Integrated  Technical 
Information  Service  (CITIS)  data. 

The  GCO  is  developed  by  the  Government  acquisition  team  with  input  from  other  supporting 
Government  activities  involved  in  the  life-cycle  support  of  the  defense  system.  The  GCO  should 
be  included  in  the  RFP  (Section  J)  as  Government  Furnished  Information  (GFI). 
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5.3  About  the  Tool 


The  tool  requires  extensive  input  of  program  information  dealing  with  the  following; 

•  Program’s  supporting  activities 

•  Data  use  and  how  it  is  used 

•  Infrastructure  in  place  at  each  activity 

•  Activities’  experience  with  the  CALS  standards  and  automated  information  systems 

For  a  greater  understanding  of  CALS,  Joint  Continuous  Acquisition  and  Life-cycle  Support 
(JCALS),  and  IDE,  refer  to  Appendix  B.  This  information  can  be  analyzed  by  the  software  and 
used  by  the  Program  Manager  to  determine  the  requirements  and  data  environment  that  will  be 
described  in  the  GCO.  The  GCO  document  is  generated  from  a  database  of  text  based  on  actual 
GCOs,  which  is  then  tailored  by  the  Program  Manager  to  suit  the  program’s  requirements.  The 
final  output  is  either  a  digital  or  hard-copy  version  of  the  GCO  document,  including  both  the  text 
and  selected  data  tables. 

The  GCO  Generator  was  originally  developed  in  1995  as  a  Navy  software  tool  (version  1.0).  The 
new  version  2.0  is  a  DoD  version  that  incorporates  information  from  all  of  the  services.  Version 
2.0  is  not  readily  compatible  with  1 .0  because  of  many  changes  made  to  the  GCO  text  database. 
Since  a  rewrite  of  the  1.0  version  has  been  completed,  any  previously  developed  data  should  be 
regenerated  with  version  2.0  to  produce  the  GCO  text  sections. 

5.4  The  GCO  Process 


The  steps  shown  below  are  performed  as  part  of  the  data  collection,  input,  and  analysis  steps  in 
the  GCO  Generator.  This  information  is  presented  in  MIL-HDBK-59B. 


Figure  5-1.  GCO  Development  Process 


5-2 


1.  Identify  what  types  of  data  are  required 

Product  description  data 
Logistics  plans  and  reports 
Publications 

Management  and  administrative  data 

2.  Identify  who  will  use  the  data 

Management 

Engineering/Design 

Supply 

Training 

Manufacturing 

Maintenance 

3.  Identify  what  the  user  will  do  with  the  data 

View  only 
Comment/ annotate 
Update/maintain 
Extract/process/  transform 
Archive 

4.  Identify  the  user’s  infrastructure 

Hardware 

Software 

Networks 

5.  Identify  the  type  of  digital  data  deliverables 

Composed  products 
Processable  data  files 

6.  Determine  the  required  data  format 

Document  image  file 
Text  file 
Graphics  file 
Alphanumeric  file 
Audio/visual  file 
Integrated  data  file 

7.  Determine  what  data  interchange  standards  are  required 

Document  image  standards 
Text  standards 
Graphics  standards 
Application  unique/data  standards 

8.  Determine  the  mechanisms  and  type  of  media  for  data  delivery/access 

Hard-copy 

Physical  (magnetic  tape,  optical  disk) 

Online  (CITIS) 

Telecommunications  (DISN,  OSI,  contractor  specific) 

5.5  Generator  Process 

This  GCO  Generator  tool  is  designed  to  lead  the  Program  Manager  through  the  GCO 
development  process,  encompassing  the  following  five  steps: 
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•  Data  Collection.  This  step  involves  creation  of  a  data  collection  survey  that  is  distributed  to 
supporting  activities,  preferably  along  with  the  normal  data  call  information.  This  survey  will 
gather  information  regarding  the  activities'  infrastructure,  data  use  requirements,  IDE 
requirements,  and  experience  with  CALS  standards  and  Automated  Information  Systems 
(AISs). 

•  Data  Input.  Once  the  surveys  have  been  distributed,  completed,  and  returned,  all  the  data  they 
contain  is  entered  into  a  series  of  data  tables.  There  is  no  requirement  that  data  be  entered 
into  all  the  tables  -  only  those  that  are  needed  by  the  program. 

•  Data  Analysis.  Data  from  the  surveys  is  now  analyzed  to  help  determine  the  most  common 
data  formats  and  the  overall  experience  with  AISs  (plus  which  ones  to  select  for  use  by  the 
program). 

•  CmS  Decision.  Once  the  data  has  been  analyzed,  the  Program  Manager  can  determine 
whether  or  not  and  to  what  extent  a  CITIS  should  be  implemented  for  the  program. 

•  GCO  Creation.  After  all  the  data  is  analyzed,  writing  the  text  of  the  GCO  begins.  The  text 
contains  five  sections: 

1 .  Introduction 

2.  CALS  Implementation 

3.  Data  Requirements 

4.  IDE  Requirements 

5.  IDE  Infrastructure 


After  all  these  tasks  are  complete,  the  GCO  Generator  allows  the  preparer  to  view  all  the  GCO 
text  assembled  on  one  form  for  final  changes  and  then  print  the  final,  complete  GCO. 

5.6  Selection  of  lETM  Functionality 

Where  the  GCO  assists  the  Program  Manager  in  identifying  the  types  (lETM,  drawing  packages, 
etc.)  and  the  interchange  standards  (SGML,  PDF)  of  digital  deliverables,  the  lETM  CONOPS 
assists  the  PM  in  determining  lETM  functionality.  Therefore,  after  the  decision  to  procure  an 
lETM  has  been  made,  the  lETM  CONOPS  should  be  developed.  Whether  acquiring  new  data  or 
converting  existing  data  for  use  in  an  lETM,  the  program  must  make  key  decisions  in  three 
areas: 


a.  Functionality  -  The  features  and  capabilities  that  are  desired  to  support  users. 

b.  Standards  -  Government,  commercial,  performance  or  other  specifications,  standards, 
conventions,  etc.  that  will  be  used  to  establish  hardware/software  interfaces  and  to  ensure 
data  neutrality,  transportability,  and  survivability. 
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c.  Data  structure  -  The  method  for  creating  or  assembling  the  data  and  effectively  and 
affordably  managing  it  throughout  its  life  cycle. 

Each  decision  acts  as  an  enabler,  facilitator,  or  constraint  on  other  decisions.  The  selection  of 
functionality  has  critical  impact  on: 

•  Cost  and  time  required  for  conversion 

•  Functionality  available  to  the  users 

•  Costs  and  ability  to  maintain  and  update  the  data 

•  Ability  to  interface  and  interact  with  other  data  files 

•  Ability,  cost,  and  effort  to  migrate  to  newer  technology  in  the  future. 

5.7  Concept  of  Operations  (CONOPS)  Acquisition  and  Support  Planning  Process 

The  first  step  in  defining  lETM  functionality  is  to  develop  an  lETM  CONOPS.  It  is  vital  that  the 
PM  team  preparing  this  document  the  many  interacting  factors,  assumptions,  and  considerations 
that  formulate  an  implementation  strategy.  This  is  done  in  the  lETM  CONOPS, ^  which 
establishes  the  conditions  within  and  under  which  the  lETM  will  function.  Preparing  the 
CONOPS  should  clarify  issues  and  establish  parameters  to  help  a  manager  select  optimal  lETM 
functionality  levels  consistent  with  program  requirements.  If  lETM  development  is  to  be 
contracted  out,  the  CONOPS  provides  key  information  to  the  bidders. 

Whether  an  lETM  is  being  acquired  as  part  of  a  new  hardware  system,  or  is  being  converted 
under  contract,.the  resulting  CONOPS  will  be  referenced  in  the  Request  for  Proposal  (RFP), 
Statement  of  Work  (SOW),  Statement  of  Objectives  (SOO),  or  Work  Order  -  along  with  the 
environment  within  which  the  lETM  will  be  developed,  fielded,  and  used.  Additionally,  the 
SOO/SOW  should  include  other  information  as  required  to  help  bidders  prepare  their  proposals 
and  assist  the  program  staff  in  evaluating  the  responses  to  required  and  desired  functionality 
requirements. 

The  decision  on  the  optimum  class  of  lETM  can  result  from  the  accumulation  of  information 
from  all  of  the  factors  in  the  CONOPS  or  from  any  single  factor  (e.g.  remaining  service  life, 
complexity  of  the  system).  The  decision  also  may  be  made  solely  to  satisfy  external  factors 
(such  as  direction  from  higher  authority,  required  interface  with  other  systems  or  manning). 
Consequently,  the  CONOPS  is  not  intended  to  be  a  “score  sheet”  with  a  weighted  quantitative 
value  for  each  factor  and  a  “right”  answer.  Instead,  it  provides  a  “check  list”  of  items  to  be 
included  in  the  deliberative  process  to  ensure  that  the  cognizant  manager  is  assisted  in  selecting 
the  highest  level  of  automation  and  best  class  of  lETM  for  his  or  her  program.  New  conditions, 
such  as  changes  in  training  philosophy,  budget  reductions,  program  phasing,  evolving 
functionality  requirements,  emerging  technologies,  etc.,  may  require  that  the  CONOPS  and  its 
associated  decisions  be  reviewed  and  changed. 

5.8  Role  of  the  CONOPS 
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The  lETM  CONOPS  guides  the  program  in  identifying  and  projecting  the  characteristics  of  the 
hardware  system  (whether  already  in  the  field  or  in  process  of  acquisition)  which  the  lETM  will 
support.  (A  sample  CONOPS  for  the  fictional  "Sagittarius  System"  is  included  as  Appendix  H). 
This  helps  to  define  the  functionality  of  the  supporting  lETM. 

•  The  lETM  CONOPS  helps  programs  define/plan  the  processes  required  for  the  life-cycle 
support  of  the  lETM.  The  lETM  Functionality  Determination  Model  (Figure  5-2)  uses 
system  attributes  data  to  determine  the  functionality  required  to  support  the  intended  lETM 
users.  Interplay  between  items  in  the  CONOPS  and  the  decisions  of  this  model  may  result  in 
a  number  of  iterations  before  the  plan  is  finalized. 

•  Completion  of  the  CONOPS  provides  a  tailored  document  that  highlights  processes,  issues, 
and  considerations  related  to  the  successful  implementation  of  lETMs  in  both  program  and 
DoD  terms.  When  complete,  the  CONOPS  will  provide  a  common  structured  document  that 
describes  the  anticipated  factors  and  environment  that  affect  lETM  development  and  use. 


Figure  5-2.  lETM  Functionality  Determination  Model 

•  The  lETM  CONOPS  will  provide  program  personnel  and  bidders  with  a  broad  perspective  of 
the  range  of  factors  and  issues  affecting  their  proposed  lETM  solution.  The  Government  also 
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will  use  the  CONOPS  to  evaluate  how  well  a  bidder  has  understood  and  met  the  program’s 
lETM  needs.  Development  may  be  iterative.  New  conditions  such  as  budget  reductions, 
program  phasing,  emerging  technologies  and  evolving  functionality  requirements  may 
necessitate  a  review  of  the  CONOPS  and  a  reevaluation  of  some  or  all  decisions. 

•  Finally,  a  key  benefit  of  developing  a  CONOPS  is  that  change  is  discussed  as  a  part  of  the 
lETM  development  process.  Factors  critical  to  lETM  success  are  highlighted  in  the 
CONOPS  and  monitored  so  that  changes  which  impact  EETMs  can  be  quickly  noted.  This 
helps  to  ensure  that  a  proposed  solution  is  not  overtaken  or  overwhelmed  by  events  or 
technology.  Decision  processes  are  revisited  and  parameters  adjusted,  if  necessary,  to  ensure 
continued  success. 

Instructions  for  Figure  5-2 

Step  1:  The  program  identifies  or  projects  the  attributes  of  the  system  or  equipment  as  they 

relate  to  the  lETM,  as  the  first  step  in  developing  the  lETM  CONOPS. 

Step  2:  Does  the  user  require  an  expert  system?  Expert  systems  capture  and  broadly  share 

technical  support,  where  minimal  levels  of  technical  support  may  be  available.  They 
provide  the  user  with  subject  matter  expertise  that  expands  user  levels  of  knowledge 
and  detail,  augments  skills,  and  improves  diagnostic  and  maintenance  procedure 
accomplishment  for  complex  systems.  Training  and  foreign  military  support 
requirements  should  also  be  considered  when  evaluating  expert  system  requirements. 
The  following  lists  some  examples  of  system  characteristics  that  may  require  the  use 
of  expert  systems: 

—I  In  a  new  design  where  the  diagnostics  and  processes  are  clearly  laid-out  and  ready 
for  incorporation  with  an  expert  system. 

-1  A  highly  complex  system  with  complex  troubleshooting  or  fault  isolation 
procedures.  The  expert  system  keeps  track  of  what  has  been  done,  what  is  next, 
other  possibilities,  etc. 

-1  Critical  systems  needing  reduced  time  from  diagnostics  to  repair  (e.g.,  flight  line 
download  and  processing,  online  sensors  connected  to  the  expert  system). 

Reduced  maintenance  cost  from  higher-quality  repair,  reduced  false  return  rates, 
“smarter”  maintenance  from  system  “learning,”  more  concise  and  accurate  parts 
orders. 

—1  Systems  requiring  supplemental  training  of  all  types. 

Step  3:  Is  the  lETM  and/or  the  expert  system  to  be  integrated  into  the  weapon  system?  Some 

systems  have  the  operating  systems  available  that  can  support  the  processing  of  lETM 
viewing  software.  This  efficient  use  of  computer  processing  capability  minimizes  the 
computer  components  required  to  support  the  lETM.  Is  it  intended  that  the  expert 
system  be  embedded  within  the  lETM.  If  so,  this  may  present  additional  hardware, 
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software,  and  interface  requirements.  If  integration  of  the  lETM  and/or  expert  system 
with  the  weapon  system  or  embedding  of  the  expert  system  within  the  lETM  is  not  a 
requirement,  Class  V  functionality  can  be  achieved  through  an  independent  system 
interface.  If  the  lETM  does  not  need  to  be  integrated,  it  can  have  a  linearly  structured 
database  as  found  in  Class  I-III  lETMs,  which  allows  the  entire  TM  to  be  printed  for 
field  and  other  users  until  all  are  outfitted  with  display  hardware.  The  lETM  display 
infrastructure  must  also  consider  any  potential  training  and  foreign  military  display 
support  requirements. 

Step  4:  Is  the  user  outfitted  with  display  hardware;  are  the  display  hardware  maintenance 

processes  in  place  to  support  these  displays? 

Step  5:  If  the  user  is  not  otfitted,  or  has  no  current  plans  to  be  outfitted,  with  the  lETM 

display  hardware  needed,  the  program  may  adopt  a  less  capable  strategy  that  allows 
for  continued  production  of  hard-copy  (HC)  TMs. 

Step  6:  Is  the  lETM  application  a  new  acquisition  or  conversion  of  existing  legacy  TMs? 

Step  7:  The  costs  for  conversion  to  Class  I  and  II  lETMs  are  fairly  well  understood  because 

of  each  Service’s  TM  digitization  efforts,  while  the  cost  of  conversion  to  the  higher- 
level  Classes  is  still  evolving.  Management  decisions  on  the  granularity  and  level  of 
indenture  needed,  will  also  significantly  impact  these  costs.  The  Program  Manager 
must  decide  whether  the  relatively  high  conversion  costs  for  Class  IV  and  V  lETMs 
are  offset  by  improvements  in  task  performance  and  savings  achieved  in  maintaining 
the  database. 

In  addition  to  the  system  or  equipment  attributes  discussed  above,  the  following 
factors  should  be  considered  or  emphasized: 

•  Periodicity  of  updates  -  More  frequent  updates  will  result  in  substantially  more  savings 
(cost  avoidance)  as  compared  with  other  lETM  update  processes. 

•  Configuration  volatility  -  Object-oriented  databases  are  very  efficient  in  managing  data  in 
support  of  multiple  configurations  of  complex  systems.  For  fairly  static  systems,  the 
advantages  are  less  significant. 

•  Quantity  of  legacy  data  involved  in  support  of  the  system  -  If  a  large  amount  of  legacy 
data  exists  (e.g.,  greater  than  500  pages),  there  is  typically  a  lot  of  repeated  data  (e.g., 
WARNINGS,  CAUTIONS,  NOTEs,  procedures,  descriptions).  Redundant  data  can  also  be 
significantly  reduced  with  re-authoring.  An  object-oriented  database  provides  the  most 
efficient  method  to  store,  maintain,  update  and  use  this  data. 

•  Cost  reduction  -  With  new  lETM  authoring  tools  being  implemented  in  applications  that 
require  a  significant  reuse  of  data,  it  has  been  proven  that  lETM  changes  can  be  produced 
at  50  percent  of  the  cost  incurred  in  producing  hard-copy  changes  using  traditional 
publishing  processes. 
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•  Maturation  -  Object-oriented  database  strategy  planning  is  a  new  field,  with  only  a  limited 
number  of  applications.  There  are  still  only  a  few  Class  IV  and  V  lETM  tools  currently 
available  commercially. 

Step  8:  Create  an  lETM  with  Class  V  functionality. 

Step  9:  If  a  Class  V  conversion  is  not  cost  effective  when  considering  its  benefits  over  the 

life-cycle,  then  the  program  must  reevaluate  the  lETM/system  requirements  and 
optimize  them  to  meet  budgeting  requirements.  Programs  should  also  consider 
implementing  TF.TMs  in  a  phased  approach,  which  helps  lower  cost  impacts  over 
time. 

Step  10;  Do  the  contents  of  the  manual(s)  and  the  attributes  of  the  hardware  system  support 
Class  m  and  IV  functionality?  Several  factors  need  to  be  considered  to  determine 
whether  Class  III  or  IV  functionality  is  the  most  cost  effective  in  support  of  the 
system.  The  following  factors  should  be  considered; 

•  quality  of  the  data  •  configuration  volatility 

•  complexity  of  the  system/equipment  •  manning  requirements 

•  conversion  costs  •  training  levels 

•  system  maintenance  levels  •  contractor  and  Government  infrastructure 

Step  11;  Are  there  plans  to  deploy  the  lETM  in  the  field?  In  particular,  if  the  lETM  is  to  be 
Class  rv  (object  database),  “print  screen”  may  be  the  only  printing  option.  As  all 
data  will  be  conveyed  via  the  display  hardware,  it  is  imperative  that  the  field  will 
have  the  appropriate  display  hardware  and  the  support  processes  needed  to  maintain 
the  lETM  and  lETM  hardware  in  place.  The  lETM  display  infrastructure  must 
consider  any  potential  training  and  Foreign  Military  display  support  needs. 

Step  1 2;  Is  the  lETM  application  a  new  acquisition  or  a  conversion  of  existing  legacy  TMs? 

Step  13;  Using  the  factors  in  Step  10,  determine  the  costs  and  benefits  of  Class  III  and  IV 
lETMs,  and  whether  the  budget  will  support  a  Class  IV  lETM  conversion  process. 

Step  14;  If  program  budgets  support  the  conversion  effort,  convert  the  legacy  data  into  a  Class 
IV  lETM  by  creating  an  hierarchical  structure  within  an  object-oriented  DBMS  using 
MIL-PRF-87269. 

Step  15;  Is  the  lETM  application  a  new  acquisition  or  a  conversion  of  existing  legacy  TMs? 

Step  16;  If  a  Class  IV  functionality  is  not  required,  conversion  is  not  cost  effective,  or  the  field 
will  not  be  outfitted  with  display  hardware  in  an  appropriate  time,  then  the  program 
should  determine  whether  converting  legacy  TMs  into  an  lETM  having  Class  III 
functionality  is  cost  effective  and  affordable.  The  primary  element  of  Class  HI 
lETMs  is  the  use  of  view  packages.  They  can  emphasize  specific  subject  matter 
content  within  the  lETM  and  then  present  the  user  with  only  data  pertaining  to  the 
subject  controlled  by  the  view  package.  An  lETM  can  have  several  view  packages. 
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each  emphasizing  a  different  subject  (e.g.,  operator  training,  overhaul  procedures, 
system  overview).  The  user  might  also  be  able  to  select  view  packages  for  novice, 
intermediate,  and  expert  levels  —  each  presenting  or  emphasizing  the  data  differently. 

Step  17:  If  view  packages  are  needed  and  affordable,  convert  the  legacy  TM  into  a  Class  III 
lETM. 

Step  18:  Is  the  lETM  application  a  new  acquisition  or  conversion  of  existing  legacy  TMs?  If  it 
is  a  new  acquisition,  the  minimum  functionality  that  should  be  procured  is  Class  II. 

Step  19:  Determine  if  frequent  updates  to  the  TM  are  required.  If  so,  an  lETM  having  Class  II 
functionality  is  preferred  over  Class  I. 

Step  20:  Determine  whether  the  ability  to  perform  “word  searches”  would  significantly  benefit 
the  user.  This  benefit  must  be  weighed  against  the  cost  to  convert  the  hard-copy  into 
ASCII  or  other  neutral  format  such  as  PDF,  plus  the  cost  of  proofing  the  resultant  file 
to  ensure  that  it  accurately  represents  the  hard-copy.  If  it  is  determined  to  be  cost 
effective,  an  lETM  having  Class  II  functionality  is  preferred. 

Step  21:  If  a  digital  file  of  the  legacy  TM  is  available,  the  program  should  convert  the  legacy 
data  into  an  lETM  having  Class  II  functionality.  The  cost  to  convert  existing  digital 
files  into  lETMs  having  Class  II  functionality  is  well  worth  the  expense,  by  being 
able  to  use  an  automated  publishing  system  to  update  information,  as  well  as  giving 
better  navigational  features  (word  searches,  links,  etc.)  to  the  user.  Note  that  each  of 
the  Services  has  already  completed  major  TM  digitization  efforts  that  have  resulted  in 
either  Class  II  lETMs  or  files  easily  convertible  to  Class  II. 

Step  22:  If  Class  II  lETM  cost  of  conversion  can  be  supported,  convert  the  data  into  an  lETM 
having  Class  II  functionality. 

Step  23:  Convert  the  legacy  data  into,  or  acquire  the  lETM  having  Class  II  lETM 
functionality. 

Step  24:  If  Class  II  lETM  cost  of  conversion  cannot  be  supported,  convert  the  legacy  TM  into 
a  Class  I  lETM. 

5.9  Inclusion  in  the  Statement  of  Work/Objectives  (SOW/SOO) 

The  information  presented  in  the  CONOPS  is  not  intended  to  be  exhaustive.  But  it  should 
include  the  primary  management  considerations  when  deciding  a  program’s  optimal  lETM  level. 
Whether  an  lETM  is  being  acquired  as  part  of  a  new  hardware  system  or  being  converted  under 
contract,  the  resulting  CONOPS  will  be  referenced  in  the  SOW/SOO  -  along  with  the 
environment  within  which  the  lETM  will  be  developed,  fielded,  and  used.  Additionally,  the 
CONOPS  should  indicate  other  information  that  helps  bidders  propose  their  systems  and,  in 
addition,  helps  the  program  staff  evaluate  the  responses  to  the  required  and  desired  functionality 
requirements.  Do  not  substitute  detailed  descriptions  and/or  “laundry  lists”  of  highly  desirable  or 
mandatory  features  for  firm  requirements.  This  may  restrict  all  bidders  to  a  solution  that  may  or 
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may  not  be  optimal,  or  that  unnecessarily  drives  up  the  cost  of  the  proposed  solution.  Where  the 
program  has  decided  on  specific  features,  functionality,  or  characteristics  that  are  required  to 
support  various  aspects  of  the  system,  they  should  be  reflected  in  the  SOW/SOO  and  Technical 
Manual  Contract  Requirements  (TMCR). 

5.10  CONORS  Development 

Development  of  the  CONORS  involves  analysis  of  the  hardware  or  weapon  system  being 
supported.  It  also  involves  determination  of  the  functionality  required  by  the  users  of  the  system, 
and  consideration  of  a  variety  of  other  factors  that  will  be  documented  in  separate  paragraphs  of 
the  CONORS.  The  following  paragraphs  suggest  a  sequence  in  which  applicable  subjects  are 
covered  in  the  CONORS,  and  they  describe  what  those  paragraphs  need  to  contain.  Other 
paragraphs  or  information  that  are  deemed  relevant  to  the  common  understanding  of  the  system 
and  its  operating  environment,  the  lETM  and  its  operating  environment,  and/or  any  unique 
conditions  may  be  added.  Use  the  outline  below  as  a  guide  to  develop  your  CONORS. 

1 .  Weapon  System/Equipment  Attributes  and  Factors  Influencing  or  Dictating  Functionality 

2.  lETM  Functionality  Determination 

3.  lETM  Implementation  Schedule 

4.  Urgency  and  Frequency  of  Information  Update 

5.  DTDs  and  FOSIs 

6.  Graphics 

7.  Links  to  Other  Information  Resources 

8.  Security 

9.  lETM  Licenses 

10.  Development  of  lETM  View  Rackage  Requirements 

11.  Technical  Manual  Identification  Number 

12.  Deficiency  Reporting  Rrocess 

13.  Media  Identification  Labels 

14.  Building  CD-ROM  Deliverables 

15.  Display  Hardware,  Operating  Systems  and  Networks 

16.  Environmental  Conditionals  and  lETM  Display  Hardware 

17.  Display  Hardware,  and  Software  Maintenance  and  Support 
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CHAPTER  6 

CLASS  CONVERSION  MODELS  AND 

PROCESSES 


6.1  Introduction 

Although  it  is  not  incumbent  upon  acquisition  managers  to  understand  the  intricate  details 
involved  in  developing  an  lETM,  they  should  become  familiar  at  a  top  level  with  the  decision 
making  process  required  to  field  an  lETM.  This  section  has  been  extracted  from  the  Draft  lETM 
Process  Plan  as  a  guide  through  the  steps  to  convert  legacy  data  to  lETM  format  or  to  prepare  for 
a  new  lETM  development  program. 

6.2  Conversion  Decisions 

The  program  decision  to  convert  data,  usually  from  hard-copy  to  a  digital  format,  involves  a 
commitment  of  resources  to  reduce  costs  and  to  improve  availability,  productivity,  and  quality. 
Although  the  lETM  CONOPS  is  generally  associated  with  a  new  acquisition,  many  of  the  issues 
and  decisions  confronting  a  manager  are  the  same  for  a  conversion  project. 

This  section  provides  information  and  considerations  on  converting  data  from  an  existing  legacy 
(generally  hard-copy  or  basic  word  processing  format)  to  an  acceptable  digital  format  with 
functionality  that  will  benefit  the  user.  It  also  presents  a  functionality  decision  model  that  will 
assist  the  cognizant  manager  in  selecting  the  best  conversion  model  for  his  or  her  program.  This 
is  the  critical  first  step  in  developing  an  lETM  CONOPS,  which  will  establish  the  conditions  in 
which  the  lETM  will  be  expected  to  function. 

While  reading  this  section,  keep  in  mind  that  each  of  the  Services  is  either  involved  in  or  has 
already  completed  major  technical  data  conversion  efforts.  These  efforts  primarily  encompass 
conversion  from  hard-copy  (paper  or  aperture  cards)  to  either  Class  I  (raster)  or  Class  II  (Indexed 
PDF)  formats.  Therefore,  any  conversion  required  by  the  program  would  typically  be  from  one 
of  these  formats  to  a  higher  level  of  DETM  -  not  from  the  original  data  format.  For  example, 
instead  of  having  to  convert  from  paper  to  a  Class  IV  lETM,  the  data  would  be  converted  from  a 
Class  n  to  a  Class  IV  lETM  with  an  associated  reduction  in  conversion  cost. 

Figure  6-1  provides  a  general  overview  of  the  process  for  converting  legacy  TMs  into  lETMs. 
The  decision  on  what  type  of  lETM  to  select  is  critical,  as  it  impacts  cost  of  conversion, 
functionality  available  to  the  user,  costs  and  ability  to  maintain  and  update  data,  ability  to 
interface  and  interact  with  other  data  files,  and  the  ability,  cost,  and  effort  to  migrate  to  newer 
technology.  Note  that  Figure  6-1  represents  the  lETM  phases  for  conversion  to  the  preferred 
SGML-based  lETM.  However,  if  the  data  is  to  be  converted  to  PDF/IPDF  (Indexed  Portable 
Document  Format)  format,  the  only  relevant  question  is  whether  the  legacy  data  is  in  digital  or 
hard-copy  format.  The  two  options  are: 

a.  Data  in  digital  format  (e.g.,  ASCII  or  native  file  format)  -  Output  directly  to  PDF  format. 
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Figure  6-1.  lETM  Conversion  Process 

b.  Hard-copy  -  Scan  in  the  data  and  then  run  either  the  Adobe  Acrobat  Capture  program  to 
convert  directly  to  PDF  format,  or  run  an  Optical  Character  Recognition  (OCR)  program 
to  convert  it  to  a  format  that  can  be  processed  (e.g.,  word-processing).  At  this  point, 
convert  it  to  PDF/IPDF. 


Step  1:  If  the  ASCII  file  including  digital  graphics  (typically  from  a  publishing  or  word 

processing  system)  of  the  TM  can  be  obtained,  the  cost  of  converting  and  proofing 
can  be  avoided. 

Step  2:  If  ASCII  is  not  available,  the  existing  TMs  must  be  converted  from  hard-copy  into 

ASCII  text  using  OCR  software,  and  graphics  can  be  taken  in  various  vector  or  raster 
formats.  In  some  cases  the  capability  exists  to  go  directly  from  the  ASCII  files  into 
the  authoring  software,  as  indicated  by  the  dashed  line  from  box  2  to  4  in  Figure  6-1 
above. 

Step  3:  When  lETM  development  is  contracted  out,  SGML  tagged  data  should  be  acquired  to 

provide  the  program  with  the  benefits  described  in  the  CONORS.  Most  lETM 
software  tools  allow  commercial  publishing  formats  to  be  processed  directly  through 
the  lETM  authoring  software.  Programs  acquiring  the  data  in  this  manner  must  be 
careful  not  to  become  locked  into  a  single  contractor  or  vendor  product  as  the  only 
source  capable  of  maintaining  the  lETM  database. 

Step  4:  The  SGMI7 ASCII  data  is  processed  through  an  “lETM  authoring  software”  to 

provide  the  features  that  the  program  determined  it  needs  to  support  its  system. 

Step  5;  Conversion  may  result  in  data  errors.  The  data  must  be  re-validated  and  re-verified  to 
ensure  that  the  converted  data  file  is  an  accurate  representation  of  the  original.  Where 
the  conversion  is  from  hard-copy  to  ASCII,  the  verification  is  straight-forward. 
However,  where  the  conversion  includes  linking,  processing,  dividing,  re-authoring 
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or  replacing  data  (e.g.,  with  video),  an  engineering  certification  must  occur.  It  will 
follow  the  normal  TM  validation  and  verification  processes. 

Step  6:  The  result  of  lETM  authoring  software,  a  “runtime”  version,  may  be  a  proprietary  file 

that  can  be  viewed  only  through  vendor  proprietary  software.  To  avoid  this  problem, 
the  acquiring  program  should  obtain  an  SGML  or  commercial  format  file  that  is 
compatible  with  its  own  TM  support  infrastructure.  There  are  some  lETM  viewing 
software  packages  that  use  the  native  SGML  file  in  the  viewer  and  therefore  eliminate 
any  proprietary  concerns.  Distribution  may  be  on  CD,  other  electronic  media  or 
across  the  Internet. 

6.3  Legacy  Conversion  Processes 

6.3.1  Raster  Conversion  Process 

While  some  conversion  from  hard-copy  to  raster  may  continue  to  be  required  to  update  existing 
raster  manuals,  it  is  being  phased  out  for  new  conversion  efforts. 

6.3.2  Service  Conversion  Efforts 

All  of  the  Services  are  currently  involved  in  the  conversion  of  drawings  and  documents  into 
digital  formats.  Descriptions  of  Air  Force,  Navy,  Army  and  Marine  Corps  efforts  are  provided  in 
Appendices  D,  E,  F  and  G. 

6.3.3  Class  II  Conversion  Model 

Figure  6-2  describes  the  general  process  involved  in  converting  a  hard-copy  TM  into  a  Class  II 
EETM.  TMs  can  be  converted  to  Class  II  from  existing  legacy  hard-copy  TMs  or  they  can  be 
acquired  as  Class  II  source  data  from  the  authoring  contractor  or  Government  activity. 
Acquisition  involves  a  slightly  different  decision-making  process  than  conversion  and  is 
described  in  detail  in  Chapter  4  of  this  document.  As  with  Class  I,  development  processes  exists 
that  may  relieve  the  program  of  many  conversion  costs. 
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Figure  6-2.  Class  II  lETM  Conversion  Process 
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Step  1:  Determine  required  linkages.  They  enable  the  user  to  select  a  desired  item  of  data  by 

having  the  lETM  locate  and  present  data  to  the  user.  The  front  matter  (e.g.,  table  of 
contents,  lists  of  figures  or  tables)  contains  examples  of  specific  items  of  data  linked 
with  their  respective  location  in  the  body  of  the  lETM.  Other  examples  are:  parts  lists 
that  can  be  linked  to  the  EPB;  hazardous  chemicals  that  can  be  linked  to  warning 
statements;  and  textual  references  that  can  be  linked  to  tables,  figures,  and  drawings. 
Evaluate  which  optional  linkages  best  support  the  user  in  accessing  information  from 
the  lETM.  Optional  linkages  can  be  initiated  by  the  user  selecting  an  item  within  the 
EETM  that  links  to  external  programs  such  as  audio,  video,  an  expert  system  or 
special  applications.  The  CONOPS  contains  a  table  that  allows  the  program  to 
identify  the  type  of  linkages  that  are  to  be  applied  to  a  given  subject. 

Step  2:  Is  ASCII  text  required?  If  the  TM  has  significant  change  activity,  then  the  cost  of  an 
Optical  Character  Recognition  (OCR)  can  be  offset  by  the  savings  incurred  by 
updating  and  changing  an  ASCII  file. 

Step  3:  If  ASCII  text  is  not  required,  arrange  to  convert  to  a  non-SGML  format  such  as  PDF. 

This  can  be  further  processed  into  an  lETM  with  the  functionality  of  a  Class  II  lETM 
by  adding  an  index  and  hyperlinks.  Note  that  PDF  cannot  be  edited;  therefore,  the 
activity  producing  the  PDF  file  has  the  only  files  that  can  be  edited.  Programs  should 
always  maintain  an  editing  capability  by  acquiring  PDF  files  with  the  source  files  that 
produced  the  PDF.  PDF  files  can  either  be  created  from  the  word  processing,  or  other 
software  used  to  create  the  original  TM;  or  they  can  be  generated  as  an  output  of  the 
scanning  process. 

Step  4:  Incorporate  the  required  and  optional  linkages  determined  in  Step  1  into  the  PDF  or 

other  selected  file  format. 

Step  5:  Determine  which  software  licenses  are  held  at  the  implementing  activity  and  whether 

any  experts  are  available  to  advise  on  how  to  properly  implement  the  lETM  software. 
If  software  has  not  been  licensed  for  use  by  the  implementing  activity,  the  acquisition 
of  software  should  be  initiated.  Chapter  4  outlines  the  steps  to  be  followed  in 
procuring  lETM  software. 

Step  6:  Determine  what  Document  Type  Definition  (DTD)  will  be  used  by  evaluating  the 

structure  and  the  content  of  the  data  that  is  to  be  SGML  tagged.  DTDs  and  the 
software  selected  must  also  be  compatible.  Existing  DTDs  must  be  used  whenever 
possible.  Appendices  D,  E,  F,  and  G  explain  how  to  obtain  those  official  DTDs  that 
are  registered  with  each  Service. 

Step  7:  Determine  the  availability  of  the  TM  in  ASCII  and  the  graphics  in  raster  or  vector 

format. 
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If  an  ASCII  file  of  the  TM  does  not  already  exist,  the  hard-copy  TM  should  be 
converted  into  ASCII.  The  hard-copy  graphics  should  be  converted  into  raster  or 
vector  formats  depending  on  whether  they  need  to  be  modified.  Raster  graphics  can 
be  edited  using  “draw”  programs.  Complex  or  precise  drawings  become  more 
difficult  to  raster-edit  and  benefit  from  conversion  to  a  vector  format  using  vector 
graphics  software.  The  cost  of  converting  or  redrafting  to  vector  formats  may  be 
significant  and  the  use  of  the  software  requires  more  training;  but  subsequent  costs  of 
updating  the  drawings  and  graphics  will  be  greatly  reduced.  Most  lETM  software 
tools  allow  commercial  publishing  formats  to  be  processed  directly  through  the  lETM 
authoring  software.  Note  that  all  conversions  should  be  validated  or  certified  by  the 
appropriate  authority. 

Step  9:  The  selected  DTD  and  defined  linkage  requirements  can  be  used  to  SGML-tag  the 
ASCII  and  graphic  files.  Where  the  SGML-tagged  file  is  to  be  used  to  produce  the 
hard-copy  TM,  any  supplemental  data  that  is  presented  as  audio  or  video 
enhancements  to  the  lETM  must  also  be  tagged  and  provided  for  the  printed  text. 
Optional  linkages  must  also  provide  a  textual  identification  of  the  destination  link 
(e.g.,  a  reference  TM,  program,  database).  Paragraph  numbers  must  be  consistent  in 
both  the  hard-copy  and  lETM  to  facilitate  easy  user  reference  between  the  two 
products.  If  this  is  done,  the  SGML  file  can  be  processed  into  a  hard-copy  publishing 
system  that  ignores  all  audio-  and  video-tagged  files  when  composing  and  printing. 

Step  10:  The  resultant  SGML-tagged  database  is  the  source  file.  All  changes  are  made  to  this 
single  source  file  to  keep  configuration  control  as  simple  as  possible.  Using  the 
SGML  file  as  the  source  file  requires  an  SGML  authoring  system  or  an  SGML 
input/output  filter  to  an  existing  publishing  system. 

Step  1 1:  The  SGML  data  is  composed  into  a  publishing  system  for  hard-copy  printing.  There 
is  no  Formatting  Output  Specification  Instance  (FOSI)  used  in  this  process.  The 
printed  hard-copy  will  contain  the  same  information,  but  may  not  have  page  integrity 
to  the  lETM. 

Step  12:  Foresight  in  developing  the  SGML  file  will  allow  the  same  SGML  file  to  be  used  for 
both  hard-copy  printing  and  electronic  display.  The  SGML  file  is  processed  through 
“EETM  authoring  software”  that  produces  an  lETM  runtime  file,  which  is  then 
distributed  via  CD,  other  digital  media  or  the  Internet. 

6.3.4  Class  III  Conversion  Model 

The  Class  III  conversion  process.  Figure  6-3,  is  the  same  as  the  Class  II  process  with  one  notable 
difference:  Class  III  lETMs  have  view  packages  that  enable  the  viewer  to  present  only  selected 
data  from  the  lETM  to  the  user.  It  should  also  be  noted  that  an  object-oriented  database  can  be 
used  here  without  having  it  integrated  into  the  lETM  itself  The  creation  of  view  packages  is 
accomplished  after  the  conversion  and  SGML  tagging  of  the  data.  As  with  Class  II,  foresight 
must  be  used  in  generating  the  SGML-tagged  data  to  ensure  that  any  audio  or  video  information 
is  represented  by  text  and  graphics  in  the  hard-copy  TM.  Note  that  PDF  files  are  not  currently 
appropriate  for  use  as  Class  III  lETMs  because  they  cannot  utilize  view  packages. 


Step  8: 
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Figure  6-3.  Class  III  lETM  Conversion  Process 


Steps  1-6  Same  instructions  as  the  corresponding  steps  1-2  and  5-9  found  in  paragraph  6.3.3 
Class  n  Conversion  Model. 

Step  7:  View  packages  are  developed  using  lETM  software  tools. 

Step  8:  The  resultant  SGML  tagged  database  is  the  source  file.  All  changes  are  made  to  this 

single-source  file  to  keep  configuration  control  as  simple  as  possible.  Using  the 
SGML  file  as  the  source  file  requires  an  SGML  authoring  system  or  an  SGML 
input/output  filter  to  an  existing  publishing  system.  All  changes  to  the  source  data 
must  be  validated  to  determine  whether  they  affect  primary,  secondary,  or  even 
tertiary  linkages  in  the  view  packages. 

Step  9:  Foresight  in  developing  the  SGML  file  will  allow  the  same  SGML  file  to  be  used  for 

both  hard-copy  printing  and  electronic  display.  The  SGML  file  would  be  processed 
through  “lETM  authoring  software”  that  produces  an  lETM  runtime  file.  The 
runtime  file,  along  with  other  files,  is  then  written  to  distribution  media. 

Step  10:  The  SGML  file  can  be  used  to  print  hard-copy  TMs  by  processing  it  into  a  publishing 
system.  As  the  SGML  file  will  have  surrogate  text  and  graphics  that  represent  the 
audio  and  video  material  used,  the  publishing  system  should  be  set  up  to  ignore  all 
audio  and  video  tagged  files  when  composing  and  printing. 


6-6 


6.3.5  Class  IV  Conversion  Model 


Figure  6-4  shows  the  process  for  converting  legacy  data  into  a  Class  IV  revisable  database 
format.  While  Class  IV  lETMs  provide  significant  savings  in  maintaining  and  updating  the 
data,  the  costs  of  conversion  are  currently  high.  These  costs  are  due  to  the  re-authoring  of  the 
legacy  data  to  take  advantage  of  Class  IV  functionality.  The  major  costs  of  conversion  are  based 
on  the  following  required  tasks: 

a.  Developing  the  hierarchical  structure 

b.  Re-authoring  the  legacy  TM  to  prepare  data  for  use  in  a  database 

c.  Selecting  the  level  of  granularity  and  indenture  for  decomposing  each  section 

d.  Re-authoring  and  clean-up  to  eliminate  repetition  and  redundancy 

e.  Adding  photographs,  animations,  movies,  verbal  instructions,  and  other  supplemental 
enhancements 

f.  Naming  common  and  unique  data  objects  and  linking  them  into  a  logical  presentation 

g.  Validating  the  re-authored  information 


Figure  6-4.  Class  IV  lETM  Conversion  Process 


When  Class  IV  lETMs  are  created  from  scratch,  the  level  of  indenture  and  granularity  of  the  data 
is  optimized  at  the  lowest  or  smallest  level  (i.e.,  individual  steps).  For  conversions,  the  costs  of 
driving  all  TM  data  down  to  this  optimal  level  may  be  prohibitively  high.  However,  this  is  not 
the  only  logical  option.  Class  IV  lETMs  can  be  developed  with  the  objects  being  roughly  the 
same  size  as  comparable  objects  in  Class  III  DBTMs  (e.g.,  one  paragraph  or  a  procedure).  By 
minimizing  the  handling  of  the  objects  and  substantially  reducing  the  re-authoring  desired  or 
required,  the  conversion  costs  can  be  reduced  to  the  same  range  as  Class  III.  This  lETM  would 
have  the  presentation  features  found  in  a  normal  Class  IV  lETM,  but  would  not  be  as  robust. 
This  compromise  retains  some  redundant  data,  sacrifices  some  database  maintenance  efficiency, 
requires  more  update  effort,  and  reduces  some  flexibility.  While  some  of  the  data  may  always 
remain  in  its  initial  conversion  state,  the  program  has  the  option  of  incrementally  re-authoring 
specific  sections  of  the  TM  (e.g.,  troubleshooting)  down  to  the  appropriate  level  of  indenture 
(e.g.,  step).  These  decisions  can  be  made  on  the  basis  of  specific  maintenance  needs,  and  funds 
available. 

Step  1;  Determine  what  authoring  and  presentation  software  licenses  are  held  at  the 
implementing  activity.  Determine  whether  experts  are  available  to  assist  in 
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implementing  the  lETM  software.  If  software  is  not  licensed  for  use  by  the 
implementing  activity,  the  acquisition  of  software  should  be  initiated. 

Step  2:  Determine  the  DTD  to  be  used  by  evaluating  the  structure  and  the  content  of  the  data 

to  be  SGML  tagged.  Existing  DTDs  must  be  used  whenever  possible. 

Step  3:  Reauthor  source  data,  creating  objects  of  information  in  accordance  to  the  selected 

DTD.  Eliminate  repeated  and  redundant  data.  Create  objects  and  linkages  that  allow 
these  objects  to  be  referred  to  many  times.  Complex  or  precise  drawings  become 
more  difficult  to  raster-edit  and  would  benefit  from  conversion  to  a  vector  format, 
using  vector  graphics  software.  The  cost  of  conversion  or  redrafting  to  vector  formats 
may  be  significant  and  the  use  of  the  software  requires  more  training,  but  subsequent 
costs  of  updating  the  drawings  and  graphics  will  be  greatly  reduced.  Some  common 
hybrid  processes  allow  vector  overlays  of  changes  to  raster  graphics,  thereby  allowing 
the  use  of  vector  graphic  tools  and  precision  without  the  cost  of  complete  drawing 
conversion.  Note  that  the  appropriate  authority  must  verify  all  conversions. 

Step  4:  Name  these  objects  to  enable  the  authors  to  identify  the  object  subject  matter  content. 

The  named  objects  are  used  to  create  and  tailor  presentations  (view  packages)  to 
subject  matter  requirements.  Tailoring  can  be  done  to  many  presentation  criteria  such 
as  training,  user  knowledge  levels,  system  configuration,  subject  emphasis  and 
overviews. 

Step  5;  Determine  the  linkages  that  best  support  the  user  in  accessing  information  from  the 
BETM.  Internal  linkages  enable  the  user  to  select  a  desired  item  of  data  and  have  the 
lETM  locate  it  from  within  the  lETM  data  file  and  present  it  to  the  user.  Some 
examples  of  linkage  are:  parts  lists  to  the  Illustrated  Parts  Breakdown;  chemical 
names  included  with  warning  statements;  and  text  references  attached  to  tables, 
figures  and  drawings.  Also  identify  desired  external  linkages.  You  can  initiate 
external  linkages  by  selecting  an  item  within  the  lETM,  if  the  item  links  to  external 
programs  such  as  audio,  video,  an  expert  system  or  special  applications. 

Step  6:  Have  the  appropriate  authority  validate  the  complete  lETM  against  the  source  data  to 

ensure  that  the  same  content  has  been  conveyed  using  the  Class  IV  lETM 
functionality. 

Step  7:  Once  validated,  the  lETM  can  be  written  to  the  distribution  media  with  associated 

files  as  required. 

6.3.6  Class  V  lETM  Migration 

The  formal  Class  V  lETM  consists  of  a  Class  IV  lETM  that  shares  an  integrated  database  with 
other  associated  applications.  Consideration  should  be  given  to  the  data  configuration  issues 
entailed  when  multiple  logistics  databases  are  integrated  into  a  single  database.  The  decision 
tree  in  the  CONOPS  provides  the  model  for  determining  whether  formal  Class  V  functionality  is 
needed. 
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CHAPTER  7 

THE  FUTURE  OF  lETMS 


7.1  Introduction 

Technology  does  not  stand  still;  neither  will  the  development  or  application  of  EETMs.  New, 
more  cost-effective  methods  for  legacy  conversion  will  be  developed.  Faster  computers  and 
better  monitors  will  permit  a  wider  range  of  multimedia  use.  Users  will  demand  real-time  access 
to  data.  As  more  information  systems  are  fielded  by  the  military,  the  user  will  eventually  have 
access  to  a  completely  integrated  operation  that  includes  training,  parts  ordering/requisitioning, 
and  expert  systems. 

Responding  to  an  increasingly  likely  scenario  that  future  military  operations  will  consist  of  joint 
missions  and  in  which  one  Service  might  be  required  to  repair  another  Service’s  equipment,  DoD 
formed  the  Tri-Service  lETM  Interoperability  Committee.  The  Joint  Commanders  Group  for 
Communication  and  Electronics  (JCG-CE)  tasked  the  committee  to  develop  guidance  and  policy 
to  accomplish  the  following: 

•  Develop  a  uniform  approach  for  electronically  communicating  and  accessing  technical  data 
throughout  DoD 

•  Maximize  the  use  of  C/NDI  technology  in  the  process 

•  Develop  a  common  user  information  interface  for  field  delivery  systems 

The  committee  is  composed  of  representatives  responsible  for  lETM  policy  from  each  of  the 
services,  and  contractors  with  extensive  experience  with  lETM  development.  It  is  important  to 
point  out  that  the  committee  is  concerned  with  user  interoperability,  not  data  interoperability. 
(Another  lETM  committee  is  addressing  data  interoperability,  basically  the  implementation  of 
MIL-PRF-87269.)  The  committee  meets  on  a  bi-monthly  basis  and  is  conducting  a  DoD  study  to 
develop  a  solution  for  the  JCG-CE  and  other  lETM  development  and  delivery  issues. 

7.2  Objective  of  the  Study 

The  objective  of  the  DoD  study  has  been  to  create  a  high-level  Joint  lETM  Architecture  (JIA)  to 
guide  and  standardize  lETM  acquisition,  management,  and  display.  This  architecture  will: 

a.  Enable  maximum  interoperability  in  the  use  of  technical  information  to  meet  the  needs  of 
the  Defense  Logistics  community  in  supporting  the  material  readiness  of  the  military. 

b.  Serve  as  the  basis  for  a  formal  DoD-wide  adoption  of  the  proposed  approach  in 
promulgating  the  required  acquisition  and  field-support  policy.  To  reduce  the  risk  of 
implementation  and  to  demonstrate  utility  of  the  approach,  the  policy  recommendations 
are  based  on  a  series  of  FY99  pilot  demonstration  programs  that  will  show  the 
applicability  of  the  Architecture  to  support  lETMs  for  the  whole  spectrum  of  military 
systems. 
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7.3  Goal  for  the  Architecture 

The  primary  goal  for  the  JIA  is  to  establish  a  technical  framework  for  acquisition  and 
deployment  of  the  whole  spectrum  of  ETMs.  When  completed,  the  user  will  be  able  to  view  and 
utilize  technical  information  distributed  to  the  work  location  through  a  common  user-interface, 
no  matter  what  the  authoring  source  or  data  format.  In  so  doing,  the  DoD  will  be  able  to 
establish  a  unified  approach  to  the  acquisition,  management,  and  use  of  existing  and  newly 
procured  lETMs. 

To  meet  this  goal,  the  overall  approach  will  be  based  on  maximum  use  of  existing 
Commercial/Non  Developmental  Items  (C/NDIs),  the  Internet  and  World  Wide  Web  technology. 
Another  goal  is  to  achieve  end-user-level  interoperability  of  the  lETMs  delivered  to  and  used  by 
the  entire  DoD  Operational  Community.  In  this  context,  an  ETM  or  lETM  is  defined  as  having 
end-user  interoperability  when  it  can  enable  a  user  with  one  common,  commercially  available 
display  device,  (such  as  a  portable  personal  computer)  to: 

•  View  and  interact  with  technical  information  from  any  source  and  of  any  internal  format. 

•  Automatically  access  and  view,  by  means  of  an  electronic-link  reference  in  the  displayed 
technical  information,  additional  information  in  any  other  ETM  or  lETM. 

7.4  Technical  Approach 

The  overall  concept  of  this  JIA  effort  is  to  utilize  the  group  of  emerging  technologies  that  the 
commercial  marketplace  is  rapidly  adopting  as  the  standard  for  distributable  electronic 
documents,  which  are,  in  general,  based  on  the  technology  of  the  Internet  and  the  World  Wide 
Web.  For  security  and  operational  reasons,  the  DoD  will  not  utilize  the  public  Internet  or  the 
World  Wide  Web,  but  will  employ  essentially  the  same  technology  and  C/NDI  products  in  a 
private  and  dedicated  DoD  intranet  environment.  Such  an  approach  is  becoming  the  de  facto 
standard  for  corporate  information  distribution  systems  worldwide.  Once  this  approach  has  been 
proven  effective,  a  set  of  implementation-guidance  documents  and  performance  specifications 
will  be  developed  within  this  comprehensive,  DoD-wide,  commercially  supported  framework. 

A  major  objective  of  the  JIA  effort  is  to  demonstrate  user  interoperability  of  proprietary  and 
legacy  lETMs.  This  will  be  accomplished  by  encapsulating  them  into  a  common-view  package 
format,  which  can  be  electronically  distributed  to  DoD  intranets  and  eventually  viewed  by  a  user 
employing  a  single  interface  (i.e.,  browser).  This  process  is  referred  to  as  "object  encapsulation. 
Such  a  demonstration  will  require  the  establishment  of  the  following  technical  capabilities: 

•  An  authoring  framework  to  effectively  create  and  manage  lETM  view  packages  for  delivery 
to  the  Government,  regardless  of  which  authoring  tools  are  used. 

•  An  infrastructure  that  permits  a  military  agency  to  distribute,  manage,  and  deliver  these 
lETM  view  packages. 
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•  A  methodology  for  the  user  to  access  and  view  the  required  technical  information  and  to 
retrieve  relevant  data  from  other  lETMs,  including  those  of  other  Services,  as  necessary. 

In  order  to  achieve  interoperability,  the  interface  requirements  recommended  for  the  JIA  will  be 
specific,  but  they  will  be  constructed  so  as  to  encourage  innovative  and  effective  solutions, 
especially  in  light  of  the  constantly  expanding  technology  base.  Achieving  this  balance  has 
required  some  decisions  that  may  need  to  be  re-examined  over  time.  Whenever  possible,  the 
design  will  adhere  to  open  standards  and/or  de  facto  Internet  standards  widely  implemented  by 
multiple  vendors,  with  clear  intent  to  maximize  the  use  of  commercially  available  software 
products. 

7.5  Overview  of  the  Architecture 

The  JIA  is  firmly  based  on  proven  and  widely  accepted  Internet  and  World  Wide  Web 
technology,  implemented  as  a  private  Web  on  a  contained  intranet.  This  intranet  can  be 
configured  as  a  private  DoD  World-wide  network  (e.g.,  the  Global  Combat  Support  System  - 
GCSS),  as  a  combat-capable,  unit-wide  local  intranet,  or  simply  as  a  group  of  computers  in  close 
proximity  hard-wired  in  a  local  Ethernet  configuration.  It  can  also  be  configured  in  a  single 
display  device  (portable  or  workstation  personal  computer)  which  operates  as  both  a  client 
browser  and  a  personal  single-user  Web  server.  The  technology  for  implementing  such  an 
intranet  is  low-risk,  easily  implemented,  and  widely  understood. 

The  proposed  Architecture  is  based  entirely  on  C/NDI  technology.  The  Architecture  has  a 
dedicated  Web  intranet  with  at  least  one  Web-browser  client  and  at  least  one  Web  server  —  more 
precisely,  an  HTTP  (Hypertext  Transfer  Protocol)  server  and  its  included  file-based  store  -  as 
well  as  a  network  to  connect  them  if  they  are  not  contained  in  the  same  computer. 

The  specific  implementation  of  the  network,  which  is  typically  a  TCP/IP  (Transmission  Control 
Protocol/Intemet  Protocol)-based  network  when  more  than  one  device  is  involved,  will  typically 
vary  from  one  implementation  to  another.  As  will  be  described  more  fully  below,  the  intranet 
may  include  other  optional  database  servers  and  application  servers  in  addition  to  the  principal 
HTTP  Web  server. 

7.6  JTA  Compliance 

The  Joint  lETM  Architecture  will  be  compliant  with  the  DoD  Joint  Technical  Architecture 
(JTA).  Individual  services  or  programs  may  define  the  operating  environments  for  their  lETM 
applications,  but  neither  the  JIA  nor  the  JTA  require  a  specific  operating  system.  In  technical 
terms,  the  “glue”  (i.e.,  the  communication  protocol)  that  holds  intranet  Webs  together  is  the  Web 
protocol  HTTP  operating  over  the  communications  protocol  TCP/IP,  not  the  requirement  for 
common  operating  systems.  A  TCP/IP  network  (e.g.,  an  intranet)  can  easily  accommodate 
multiple  operating  systems  on  its  server  and  client  computers. 

7.7  JIA  Use  of  Internet  and  World  Wide  Web  Technology 

The  approach  to  developing  a  solution  for  this  interoperability  problem  has  been  to  adapt 
commercial  and  industry  applications  involving  electronic  documentation  for  which  there  is 
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widespread  vendor  product  support.  A  JIA-compliant  lETM  product  will  apply  the  vendor 
software  and  standards  being  developed  for  the  World  Wide  Web  and  the  Internet  in  a  dedicated 
and  private  intranet  environment.  Following  the  rapid  change  trend  in  Internet  technology,  the 
JIA  has  been  designed  to  be  extensible,  flexible,  and  able  to  accommodate  the  predictable  rapid 
growth  in  technology  for  all  aspects  of  the  Internet,  the  Web,  and  emerging  electronic 
documentation  applications. 

The  Web  is,  by  its  nature,  a  client/server  architecture.  On  the  client/server  spectrum,  JIA- 
compliant  lETM  applications  may  differ  in  emphasis  from  a  major  “server-centric”  trend  that  is 
emerging  for  many  commercial  enterprise  applications.  The  recommendations  for 
implementation  of  the  JIA  are  intentionally  biased  towards  a  model  employing  encapsulated 
objects  downloaded  to  a  portable  device  for  use.  In  this  approach,  the  server  is  preferred  as  a 
utility  electronic  bookshelf  for  lETM  view  packages  (i.e.,  the  package  of  encapsulated  lETM 
objects).  By  analogy,  these  digital  books  are  designed  so  they  can  easily  be  moved  to  another 
electronic  bookshelf  at  another  physical  library  site,  reflecting  the  operational  reality  of  the 
military  unit  itself.  On  the  other  hand,  commercial  Web  sites  tend  to  be  permanently  located 
corporate  resource  centers  where  servers  and  the  information  providers  are  co-located.  For  these 
commercial  activities,  the  mobile  and  less  controlled  entity  is  the  user  client.  In  these 
applications,  the  preference  is  towards  server-centric  computing  and  the  use  of  server-oriented. 
Web-object  components.  The  corporate  personnel  resources  for  maintaining  both  the  Web 
server  and  the  content  are  located  at  the  Web  site.  In  military  applications,  the  server  sites 
resemble  a  technical  library  rather  than  a  computer  information  center.  Technical  expertise  lies 
with  the  content  creator  or  the  user  and  not  the  administrator  of  the  server.  This  situation  at  this 
time  dictates  total  object-encapsulation  and  “client-centric”  computing  as  the  primary  emphasis 
of  the  JIA. 

Progress  in  Web-oriented  technology  and  the  availability  of  secure,  affordable  military  intranets 
offering  global  connectivity  may  change  this  in  the  future.  Thus,  the  JIA  is  intentionally 
designed  not  to  preclude  other  solutions,  should  such  a  change  occur.  It  is  important  to 
emphasize  that  any  implementing  policy  for  the  JIA  must  include  some  specific  guidance  on  how 
to  apply  the  Architecture,  as  well  as  the  requirement  to  conform  to  the  Architecture.  The  use  of 
custom  servers  is  an  important  issue  for  which  guidance  must  mature.  Guidance  documents  for 
the  acquisition  of  JIA-compliant  lETMs  must  be  continually  updated.  Updates  must  be  based  on 
a  continuing  study  of  emerging  military  requirements,  as  compared  with  the  current  state  of 
commercial  technology  and  available  C/NDI  commercial  products. 

7.8  Proposed  Requirement  Documents  for  Implementation  of  the  Architecture 

This  section  summarizes  initial  recommendations  for  the  baseline  requirement  documents  for  the 
JIA,  development  of  JIA-compatible  lETMs,  and  infrastmcture  capability. 

In  addition  to  requiring  the  HTTP  and  TCP/IP  networking  protocols  used  by  the  Internet  and 
commercial  Web-based  intranet  products,  the  JIA  will  be  specified  in  the  following  areas: 

•  Object  Encapsulation  and  Component  Interface.  This  specification  is  needed  for  definition 
of  the  delivery,  transport,  and  structure  of  the  integrated  collection  of  software  components 
and  data  contained  in  the  lETM  view  packages.  This  specification  includes  the  interface 
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between  multiple  components  when  they  exist,  and  the  automated  mechanisms  for  placing 
the  lETM  on  the  targeted  intranet.  It  will  also  include  requirements  for  the  capability  to 
automatically  install  these  components  on  a  user  device  in  a  manner  sufficiently  simple  so 
that  no  professional  system  administrator  is  needed.  It  will  include  a  primary  specification  to 
tell  the  lETM  developers  in  what  form  they  are  to  deliver  the  lETM  view  package. 

•  Intranet  Server  and  Database  Interface.  For  those  lETMs  that  require  the  services  of  an 
application  server  and/or  a  database  server,  the  lETM  supplier  must  provide  the  proper 
software  extensions  to  the  basic  JIA  intranet  Web  server  if  they  are  not  already  in  place.  This 
specification  outlines  cooperation  between  the  developers  of  the  user  intranet  infrastructure 
and  the  lETM  provider,  and  the  interfaces  and  protocols  involved.  The  JIA  is  designed  to 
recognize  that  it  will  be  necessary  to  install  software  using  conventional  system 
administration  practices  on  fielded  servers  in  order  to  achieve  needed  functionality.  (This  is 
not  the  case  for  the  components  fielded  on  JlA-conforming  user  browsers.)  This 
specification/guidance  document  will  provide  the  requirements  that  an  lETM  provider  must 
consider  when  proposing  or  delivering  such  a  capability  for  a  JIA  intranet. 

•  Common  Browser.  The  immediate  target  for  this  specification  will  be  the  procurers  of  user 
PEDDs  (Portable  Electronic  Delivery  Devices)  and  workstations,  since  the  installation  of  this 
standard  browser  will  be  required  for  these  devices.  The  browser  software  component  must 
be  pre-installed  on  the  PEDD  since  it  is  not  included  in  the  lETM  view  package.  lETM 
source  will  also  be  affected  by  this  specification  since  the  lETM  must  be  formed  and  viewed 
using  any  JIA-compliant  browser.  Two  products  dominate  the  Web-browser  commercial 
marketplace  at  present,  Microsoft  Internet  Explorer  and  Netscape  Navigator,  and  the  thrust  of 
this  specification  is  to  specify  the  configuration  of  each  so  that  they  will  be  functionally 
equivalent  in  any  JIA  intranet.  This  will  involve  some  extensions  to  the  commercially- 
released  products  via  plug-ins  and  controls.  There  would  be  viewing  capabilities  common  in 
military  lETMs  such  as  CGMs  or  the  common  PDF  used  for  legacy  TMs. 

•  Electronic  Addressing  and  Library  Model.  This  overarching  specification  holds  the 
enterprise  collection  of  lETM  information  together  by  means  of  digitally  encoded  and 
executable-link  references.  The  specification  itself  will  define  the  syntax  and  mechanism  for 
building  and  executing  the  automated  links  to  the  lETM  content  and  the  lETM  presentation 
software.  Two  additional  areas,  regarding  administration  and  enforcement  of  the 
recommendations,  are  needed  so  that  the  enterprise-wide  addressing  concept  will  work.  The 
Electronic  Addressing  and  Library  Model  specification  will  discuss  these  aspects,  which 
includes  the  actual  bureaucratic  administration  and  allocation  of  the  DoD-wide  lETM 
“address  space.”  This  is  the  indexing  or  Uniform  Resource  Locator  (URL)-based 
electronically  processed  numbering  system  to  which  the  services  and  their  suppliers  must 
subscribe.  The  specification  will  also  discuss  the  area  of  the  library  model  that  can  be  used 
to  perform  an  intelligent  content-based  access  to  another  lETM  when  the  exact  specific 
locator  is  not  known.  To  support  the  proposed  Library  Search  functionality,  the  specification 
will  also  specify  and  require  metadata  files,  encoded  in  extensible  Markup  Language 
(XML),  which  will  serve  as  the  primary  search  index  files. 

The  Object  Encapsulation  and  Component  Interface,  Intranet  Server  and  Database  Interface, 

Common  Browser,  and  Electronic  Addressing  and  Library  Model  technical  descriptions  are  all 
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needed  to  affect  interoperability  of  disparate  lETMs  in  the  field.  The  specific  DoD  form  of  these 
technical  descriptions  (i.e.,  whether  they  all  should  be  formal  DoD  Performance  Functional 
Specifications  or  some  other  type  of  guidance  document)  will  be  determined  at  the  time  the  final 
recommendations  are  formulated  at  the  end  of  the  DoD  Interoperability  Project. 

The  overall  interoperability  goal  is  the  ability  to  view  any  lETM  with  any  browser  that  conforms 
to  the  JIA  Common  Browser  technical  description.  It  also  requires  that  all  cross-references  by 
one  lETM  to  another  lETM  be  encoded  in  a  standard  manner  (i.e.,  in  conformance  with  the 
Electronic  Addressing  technical  descriptions)  so  that  the  lETM  browser  can  access  the 
referenced  lETM  by  a  simple  user  selection  (e.g.,  a  mouse  click).  The  other  two  specification 
areas  are  subordinate  to  these  two  user  requirements.  But  they  are  needed  to  ensure  that 
contractor-delivered  lETM  view  packages  and  the  DoD  infrastmcture  provide  the  necessary  user 
interoperability. 

The  following  paragraphs  contain  a  short  summary  of  the  concept  and  philosophy  embodied  in 
each  technical  description. 

7.8.1  Object  Encapsulation  and  Component  Interface  Technical  Description 

A  core  philosophy  underlying  this  architecture  is  that  developers  of  lETMs  can  deliver,  as  a 
single  view  package,  all  capability  in  the  form  of  data  and  software  contents  needed  to  install  and 
use  an  lETM  on  a  standard  DoD  intranet.  This  technical  description  provides  the  lETM 
suppliers  with  the  form  needed  to  package  and  deliver  the  digitally  encoded  lETM.  This  view 
package  may  contain  both  content  data  and  software  components.  These  are  combined  into 
encapsulated  objects  and  delivered  as  a  contract  package  for  electronic  archiving  or  subsequent 
store-and-forward  management.  No  provision  is  made  for  separately  delivering  an  lETM  player 
or  piece  of  viewer  software  for  installation  onto  the  user  device.  The  view  package  contains  the 
capability  to  be  automatically  installed  onto  the  user  intranet  upon  arrival. 

The  encapsulated  data  and  software  objects  will  eventually  be  delivered  by  the  operational 
infrastructure  to  the  field  user  as  though  they  were  simple  binary  data  packages.  These  packages 
will  be  treated  by  the  infrastructure  as  file-oriented  data  destined  for  an  agency  intranet  Web 
server.  The  packages  will  appear  simply  as  generic  “buckets  of  sequenced  bits”  that  make  sense 
to  the  server.  The  infrastructure  activity  need  only  make  certain  that  these  bits  remain  packaged 
together.  The  view  package  is  a  set  of  industry  standard  binary  files,  each  of  which  is  assigned  a 
JIA  notional  locator  (e.g.,  a  URL  [Universal  Resource  Locator]  conforming  to  the  JIA  addressing 
model)  that  contains  sufficient  information  to  support  its  installation  as  data  in  the  intranet  server 
file  system. 

The  complexity  and  degree  of  integration  of  these  view  packages  will  vary  greatly  among 
differing  lETMs.  Some  will  simply  be  two-part  collections  of  one  software  component  and  one 
data  set.  The  simplest  form  will  be  a  single  set  with  all  of  the  needed  software  contained  in  the 
standard  JIA  browser.  In  other  forms,  a  system  of  software  components  and  possible  multiple 
data  sets  will  spread  out  among  several  servers  and  the  browser  device  when  the  lETM  is 
operational.  This  would  be  the  case  when  background  software  agents  are  operating  that  might 
be  diagnosing  and  monitoring  systems.  Another  emerging  technology  requiring  complex  lETM 
objects  requires  software  agents  (acting  as  mentors)  to  insert  training  aids  into  the  job-aiding 
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presentation  when  the  agent  (a  computer  program)  determines  they  are  needed.  In  between  is  a 
spectrum  of  complexity,  each  level  requiring  a  different  object-encapsulation  approach.  The 
“object”  nature  of  these  view  packages  is  that  all  the  intelligence  to  construct  the  operational 
BETM  on  the  target  intranet  is  contained  within  the  view  package  objects  themselves.  There  is 
no  standard  for  the  internal  constructs  of  the  view  package  in  the  JIA.  This  is  the  characteristic 
of  the  object-oriented  approach  utilized  by  the  JIA. 

Until  the  point  of  receipt  by  the  intranet  server,  the  view  package  is  processed  as  a  single  object. 
There  are  a  variety  of  mature  approaches  for  bundling  a  set  of  files  with  headers  into  a  single 
data  set  (e.g.,  Internet  MIME  [Multiservice  Internal  Mail  Extensions]  Standards).  The 
Architecture  may  use  any  of  them,  requiring  only  that  the  view  package  can  be  installed  as  a  set 
of  files  on  the  intranet  server(s).  With  this  approach,  no  overt  man-in-the-loop  software- 
installation  processes  are  required  other  than  the  automatic  capability  built  into  Web-capable 
browsers  and  servers.  Many  technical  options  exist  for  encapsulating  view  packages;  however, 
this  requirement  for  automated  software-component  installation  using  Industry-Standard  Web 
practices  is  critical  to  determining  the  extent  to  which  an  encapsulation  approach  is  satisfactory. 

7.8.2  Server  and  Data-Base  Interface  Technical  Description 

The  simplest  way  for  the  JIA  to  achieve  lETM  interoperability  for  the  DoD  is  to  utilize  only 
generic  Web  servers.  This  approach  will  not  require  additional  software  to  be  installed  on  either 
the  servers  or  the  browser  device.  However,  some  legacy  systems  and  some  highly  innovative 
new  lETM  applications  may  require  custom  server  extensions  and  database  interface 
components.  For  complex  lETMs,  which  require  extended  services  operating  on  an  intranet 
server,  installation  will  likely  involve  two  phases.  One  phase  will  be  to  “extend”  the  intranet,  a 
process  governed  by  the  Server  and  Database  Interface  Technical  Description,  and  the  other  will 
be  to  install  the  data  and  requirea  browser  components,  a  process  governed  by  the  Object 
Encapsulation  Technical  Description. 

Final  recommendations  on  the  use  and  encapsulation  of  server  extensions  will  require  additional 
technical  investigations,  since  the  technology  and  marketplace  need  to  mature  before  the 
development  of  specific  recommendations  can  be  accomplished. 

7.8.3  Browser  Technical  Description 

In  line  with  the  philosophy  of  this  Architecture  to  use  de  facto  Industry  Standards,  the  browser 
requirements  are  established  by  the  two  particular  commercial  products,  which  together  have 
captured  essentially  the  entire  Web  browser  market.  While  it  is  possible  to  develop,  assess,  and 
evaluate  a  long  list  of  needed  and  desirable  requirements  for  the  ffiTM  browser,  such  an  exercise 
would  serve  little  purpose  in  light  of  economic  and  marketplace  realities.  New  Web  browsers 
are  software  products  that  are  very  complex  and  expensive  to  develop.  Furthermore,  the  current 
products  are  being  offered  in  the  marketplace  free  of  charge,  effectively  precluding  the 
development  of  additional  commercial  general-purpose  browser  products.  At  this  writing,  these 
two  products  are  Microsoft  Internet  Explorer  and  Netscape  Navigator.  Except  for  a  few  (but 
very  important)  capabilities  discussed  below,  these  two  products  are  functionally  identical.  For 
existing  Web  pages,  they  perform  in  a  similar  fashion. 
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The  Browser  Technical  Description  will  specify  the  appropriate  version  of  the  commercial 
browser  products  and  a  set  of  standard  extensions  (i.e.,  controls  and/or  plug-ins)  to  these 
browsers.  These  extensions  will  include  common  DoD  data  viewers  for  file  formats  such  as 
PDF,  SGMIVXML,  CGM  Version  4  Graphics,  and  CALS  raster  images.  Since  an  XML 
capability  will  be  in  the  basic  functional  set,  the  Version  5  release  of  these  two  products  will 
probably  serve  as  the  baseline.  These  will  be  the  first  versions  of  both  browsers  to  support  XML 
and  both  companies  (Microsoft  and  Netscape)  have  aggressive  plans  to  add  this  capability.  The 
inherent  capabilities  of  the  JIA-compliant  browser  will  include  basic  presentation  methods,  either 
native  to  the  commercial  browser  or  added  to  meet  JIA  requirement,  so  that  the  component 
portion  of  the  encapsulated  object  can  be  assumed  to  be  preinstalled  on  the  user  device.  In  most 
cases,  these  particular  components  need  not  be  included  in  the  view  package.  Native  browser 
support  includes  components  such  as  HTML  layout,  GIF  (Graphics  Interchange  Format) 
viewers,  and  JPEG  (Joint  Photographic  Experts  Group)  displays. 

One  major  area  of  difference  between  the  two  browsers  lies  in  the  area  of  object  brokering  and 
the  automatic  downloading  of  components.  Ideally,  it  would  be  desirable  to  require  that  lETMs 
operate  with  either  browser  in  its  out-of-the-box  form;  however,  the  JIA  Study  Team  has 
concluded  that  such  a  policy  would  restrict  some  very  needed  capabilities  regarding  the 
“downloadable”  components  needed  for  the  JIA  object-encapsulation  concept.  The  differences 
are  due  to  the  lack  of  cooperation  on  the  part  of  the  two  competing  companies  (Netscape  and 
Microsoft)  to  provide  compatible  solutions  for  the  marketplace.  The  generic  capability  to 
automatically  download  and  install  software  components  is  essential  to  the  JIA,  so  it  may  be 
necessary  to  chose  one  over  the  other  for  a  specific  implementation.  To  support  users  of 
Microsoft  Windows  95,  98,  or  NT-based  devices  (which  includes  the  vast  majority  of  portable 
devices  available),  it  is  desirable  to  utilize  products  supporting  the  Microsoft  Distributed 
Component  Object  Model  (DCOM)  object  standards  that  provide  turnkey  support  of  this  feature. 
For  communities  employing  Microsoft  software,  it  is  strongly  recommended  that  both  browser 
products  be  enhanced  (by  third  party  plug-ins  if  necessary)  to  support  DCOM  objects  (especially 
the  downloadable  ActiveX  controls).  These  are  the  most  efficient  formats  for  executable 
programs  running  in  a  Microsoft  32-bit  operating  system. 

There  is  also  a  marked  degree  of  difference  in  the  way  the  two  products  handle  Dynamic  HTML 
(DHTML),  an  emerging  technology  for  putting  intelligence  into  actual  Web  pages.  However, 
because  of  the  lack  of  consensus  in  the  vendor  community  on  DHTML  standards  and  the  fact 
that  there  are  options  for  this  functionality,  the  JIA  Study  Team  has  not  yet  establish  this 
requirement  as  part  of  the  minimal  baseline  and  currently  discourages  its  use  in  DoD  programs. 
The  eventual  goal  is  that  all  valid  DoD  lETMs  be  compatible  with  both  the  Internet  Explorer  and 
Netscape  products.  This  may  require  some  installed  extensions  to  make  the  two  products 
interchangeable  to  the  maximum  extent  possible. 

7.8.4  Electronic  Addressing  and  Library  Model  Technical  Description 

The  syntax  for  JIA  electronic  addressing  will  be  based  on  the  URL  standard  for  the  World  Wide 
Web  because  it  is  widely  implemented  in  virtually  all  Web-enabled  vendor  products.  Any 
occurrence  of  a  legitimate  URL  string  of  characters  is  automatically  made  "hot"  in  the  vendor 
application,  and  a  “mouse  click”  or  two,  on  the  hot  spot,  will  launch  a  Web  browser  search 
which  will  locate  the  file  referenced  by  the  URL  and  display  it  on  the  screen.  In  addition  to 
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requiring  a  standard  syntax,  the  Electronic  Addressing  and  Library  Model  Technical  Description 
will  also  require  that  all  of  the  Services  maintain  and  publish  a  permanent  registry  of  all  valid 
references  to  the  lETMs  issued  by  that  Service.  Once  published,  a  valid  URL  must  not  be 
changed.  This  type  of  URL  is  called  a  persistent  URL.  In  order  to  ensure  that  URLs  are  indeed 
persistent  URLs,  the  JIA  recommends  the  use  of  virtual  URLs  (vURLs).  These  are  URLs  that 
use  an  administratively  assigned  server  reference,  notated  by  URL  syntax;  however,  the 
referenced  server  exists  in  name  only.  That  is,  it  does  not  actually  exist  on  a  network  and  is  used 
for  data  management  purposes  only.  When  the  lETM  is  installed  on  a  network,  the  vURL  is 
remapped  to  the  server  where  the  lETM  data  resides.  (This  is  easily  accomplished  in  practice 
using  what  are  called  Host  files  and/or  Domain  Name  Services  (DNS)  in  accordance  with 
standard  World  Wide  Web  practice.) 

The  specification  will  address  the  requirement  for  the  remapping  of  these  vURLs  (which 
reference  a  hypothetical  server  on  the  World  Wide  Web)  into  the  actual  server  and  file  system 
locations  on  the  intranet.  The  Specification  will  also  outline  an  on-line,  search-oriented  Library 
Model  and  identify  the  requirement  for  a  standard  metadata  package  to  support  on-line  searches. 
This  metadata  package  will  be  encoded  in  XML  and  attached  to  each  lETM  view  package,  which 
will  contain  indexing  information  useful  for  automated  search  engines  in  identifying  an  lETM 
reference. 

7.9  Basic  JIA  Operational  Flow  Diagram 

Figure  7-1  shows  the  flow  of  lETMs  through  the  JIA.  It  illustrates  the  employment  of  the  JIA  by 
the  original  lETM  developer,  the  management  infrastructure  repository,  the  user-site  intranet 
server,  and  the  user  who  selects  the  next  object  to  view  via  a  point-and-click  Web-browser 
interface.  The  presentation  components  referred  to  can  be  either  client  or  s  erver  components  or 
implied  (i.e.,  omitted)  in  the  cases  in  which  they  are  preinstalled  in  the  standard  browser. 


7.10  Benefits  of  Employing  the  Architecture 

Although  implementation  of  the  JIA  produces  a  number  of  significant  benefits,  it  will  primarily 
benefit  the  end  user,  the  lETM  developer  and  the  DoD  lETM  Distribution  Infrastructure. 

7.10.1  Benefits  from  the  User  Perspective 

The  principal  benefit  of  the  JIA  is  that  the  user  will  be  able  to  utilize  a  single  device  to  read  any 
DoD  lETM,  no  matter  which  Service  originated  it.  To  accomplish  this,  the  user  accesses  and 
views  the  lETMs  with  either  a  workstation  personal  computer  in  a  shop  environment  or  a  PEDD. 
The  portable  device  will  be  configured  either  as  a  network  client  attached  to  the  unit  intranet  or  it 
will  be  reconfigured  to  operate  in  stand-alone  or  detached  mode.  In  either  case,  the  display  of 
the  information  on  the  user  interface  is  identical,  and  the  user  cannot  determine  from  the  look- 
and-feel  of  a  screen  display  the  mode  in  which  the  device  is  operating. 

A  major  benefit  of  the  JIA  to  the  user  is  that  all  information  is  viewed  through  a  common  and 
very  familiar  Web-browser  interface.  To  access  an  lETM,  the  user  selects  a  URL  reference 
using  one  of  the  many  access-screens  or  menu-select  options  available.  This  could  be  a  favorite 
list,  explicit  entry,  a  preassembled  list  of  active  lETMs  on  a  unit  Home  Page,  a  hot-spotted  index 
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graphic,  or  a  Web  page  job  assignment  form  listing  the  needed  technical  references.  All  of  these 
are  common  practices  borrowed  directly  from  the  World  Wide  Web  community.  From  the 
user’s  perspective,  the  referenced  lETM  content  simply  appears  in  the  browser  window. 

A  major  benefit  to  the  user  organization  is  that  no  explicit  software  installations  are  required  to 
utilize  an  lETM  even  on  a  new  out-of-the-box  JIA-conforming  browser  device.  Depending  on 
the  browser  security  level  set,  the  user  may,  need  to  accept  software  components  that  require 
installation  by  an  acknowledgment  but  for  which  no  explicit  installation  action  is  needed;  the 
browser  installs  the  components  automatically.  This  is  an  essential  user-friendly  feature  of  the 
JIA.  Thus,  there  is  no  need  for  a  trained  and  certified  system  administrator  to  install  user 
software. 

Another  key  benefit  of  the  JIA  is  that  the  Web-based  access  methodology  is  a  proven  “point  and 
click”  user  interface.  If  one  lETM  contains  a  reference  to  another  lETM,  the  user  can  “click”  on 
the  highlighted  reference  and  that  referenced  lETM  will  appear  in  the  browser  window 
(assuming,  of  course,  the  referenced  lETM  exists  on  the  user’s  intranet).  This  second  lETM  can 
in  turn  reference  a  third  lETM.  To  return  to  the  original  lETM,  the  user  simply  uses  the  “back” 
arrow  on  the  browser  interface,  effectively  reversing  the  references.  Modem  Web  browsers  can 
handle  many  levels  of  such  nested  referencing  with  no  performance  degradation.  From  the  user 
perspective,  the  JIA  is  thus  intended  to  make  the  use  of  disparate  lETMs  as  easy  and  “seamless” 
as  possible  with  modem  technology.  Because  of  the  nature  of  the  Web  browser  technology 
employed,  the  user  experiences  a  great  deal  of  common  “look-and-feel”  in  the  interactive 
(navigation-control)  area,  even  if  the  individual  lETM  user-interface  for  the  content  varies. 

A  common  practice  on  the  World  Wide  Web  is  the  use  of  search  engines  such  as  those  employed 
by  Yahoo  and  Excite.  The  JIA  Library  Model  and  the  required  standard  XML-encoded  metadata 
package  are  specifically  designed  to  facilitate  the  inclusion  of  search  engines  on  a  JIA- 
conforming  intranet.  In  these  search  engines,  the  user  will  enter  a  list  of  key  words  or  reference 
designators  and  the  search  engine  will  identify  possible  lETM  references  available  on  the  user’s 
intranet.  The  JIA  will  not  specify  the  search  engine,  but  a  rich  selection  of  commercially 
available  search  engines,  which  build  their  indices  from  XML-  and  HTML-encoded  sources  and 
can  easily  be  employed  on  a  JIA  intranet,  is  expected.  The  ability  to  get  all  the  information 
needed  to  perform  a  task  in  a  timely  and  convenient  manner  has,  from  the  beginning  of  the  lETM 
concept,  been  one  of  the  promised  performance-enhancing  capabilities  of  lETMs.  This  JIA 
implementation,  using  low  cost  commercially  available  technology,  will  permit  realization  of 
this  capability. 
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Figure  7-1.  Flow  of  lETMs  Through  the  JIA 
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7.10.2  Benefits  for  the  lETM  Developer 


The  principal  emphasis  of  the  JIA  from  the  lETM-developer  perspective  is  this.  All  software 
components  and  data  (needed  to  make  an  lETM  accessible  on  the  JIA  display  device)  are 
bundled  into  a  single  digital  product  (i.e.,  the  encapsulated  object),  easily  installed  as  a  set  of 
data  files  onto  an  intranet-server  file  system.  The  primary  benefit  to  the  lETM  developer  of  that 
object-oriented  concept  is  that  you  are  free  to  choose  whatever  authoring  and  development 
environment  is  preferred.  The  JIA  does  not  dictate  how  the  lETM  is  to  be  developed  nor  what 
the  internal  format  of  the  lETM  object  must  be.  External  interfaces  are  in  accordance  with 
electronic-document  authoring  environments  being  adapted  to  operate  on  the  World  Wide  Web 
and,  as  such,  should  operate  equally  well  on  a  JIA-compliant  intranet.  Proofing  tools  for  lETM 
objects  are  also  easy  to  set  up  as  a  JIA-compliant  intranet  and  JIA  browsers  are  made  up  of 
available  software  products  which  the  authoring  activity  can  procure.  Again,  the  design 
philosophy  for  the  JIA  is  to  use  the  best  readily  available  commercial  practices  for  developing 
and  deploying  lETM  products. 

While  the  technology  needed  to  bundle  all  of  the  lETM  components  into  a  single  digital  package 
is  complex,  it  is  readily  available  in  C/NDI  products.  These  are  inexpensive,  relative  to 
traditional  lETM  products,  and  easy  to  obtain.  There  has  been  an  unprecedented  rush  by 
suppliers  to  get  competitive  products  into  the  commercial  market.  A  fundamental  principal  of 
the  JIA  is  that  the  products  developed  for  the  Internet  can  be  used  to  develop  lETM  products  for 
a  JIA-compliant  intranet.  This  process  is  in  contrast  to  current  practice,  where  the  lETM  product 
is  delivered  as  two  separate  items,  the  lETM  content  data  and  the  lETM  presentation  system 
software  program. 

7.10.3  Benefits  to  the  DoD  lETM  Distribution  Infrastructure 

The  primary  benefit  of  the  JIA  to  the  DoD  lETM  digital  distribution  infrastructure  is  that 
encapsulated  lETM  objects  can  be  distributed  without  requiring  that  the  distributing  system 
know  what  is  inside  the  electronic  capsules.  The  infrastructure  activities  can  therefore  be  simple 
distribution  centers,  for  which  the  DoD  has  substantial  experience,  and  not  data-processing 
centers,  which  would  be  much  more  difficult  to  operate  and  staff. 

The  specific  design  of  and  development  of  a  specific  DoD  component  infrastructure  is  not  within 
the  scope  of  the  JIA  effort.  This  infrastructure  design  will  undoubtedly  be  a  complex  task  that 
will  be  further  complicated  by  the  impact  it  will  have  on  many  existing  business  practices. 
However,  the  JIA  element  which  enables  the  objects  to  be  processed  as  an  item  of  supply  (with 
no  requirement  to  manage  the  internal  content  or  structure  of  the  object),  should  make  this  task 
more  manageable. 

7.11  Architecture  Types 

In  practice,  the  implementation  of  an  lETM  intranet  may  be  simpler  (as  is  the  case  with  basic 
HTML  pages)  or  more  complex  (as  is  the  case  with  most  custom  servers)  than  the  baseline 
Operational  Flow  described  in  the  previous  section.  The  following  breakdown  of  anticipated 
lETM  view  packages  by  architecture  type  is  presented  to  categorize  variants  and  to  provide 
implementation  guidance.  Any  particular  lETM  intranet  implementation  will  typically  contain  a 
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mixture  of  these  types.  The  four  types  of  categories  represent  a  continuous  spectrum  of  variation 
(i.e.,  some  applications  will  be  difficult  to  categorize  precisely).  However,  identifying  the  types 
will  make  it  easier  to  present  guidance  in  the  JIA,  particularly  regarding  the  Server  and  Database 
Interface  Specification.  Definitions  of  these  Architecture  types  are  given  in  Table  7-1. 

Type  definitions  are  grouped  into  two  categories: 

1.  The  baseline  architecture,  lETM  Architecture  Types  Cl  and  C2.  Definition  of  these  two 
client-centric  Architecture  types  has  essentially  been  completed.  These  types  require 
only  a  browser  and  a  generic  HTTP  server. 

2.  The  extended  architecture.  Architecture  Types  SI  and  S2.  For  these  server-centric  types, 
the  technology  for  employing  the  additional  servers  in  the  Web  environment  is  less 
mature  and  more  diverse.  This  segment  of  the  marketplace  is  emerging  and  it  is  still 
dominated  by  proprietary  products.  This  situation  is  in  large  part  due  to  the  fact  that 
vendors  have  opened  the  browser  products  to  the  public  domain  (a  market  where  little 
money  is  to  be  made)  and  have  kept  the  server  market  proprietary  (where  vendors  see 
profit  potential  and  seek  competitive  advantage). 

7.12  Characteristics  of  Architecture  Types 

Architecture  Types  Cl  and  C2  share  common  important  characteristics;  they  do  not  require 
installation  or  operation  of  unique  software  on  the  server.  Thus,  the  server  can  be  treated  as  an 
electronic  bookshelf  As  far  as  the  server  is  concerned,  the  two  parts  of  an  encapsulated  object 
(the  data  and  the  associated  software  components)  are  simply  treated  as  files.  Additionally,  any 
contemporary  HTTP  server  can  be  employed  and  it  does  not  matter  what  operating  system  is 
utilized.  Thus,  for  Type  Cl  and  C2  lETM  applications,  interoperability  is  very  low-risk  in  the 
sense  that,  any  lETM  view  package  can  be  accessed  using  any  server.  Only  a  generic  server  is 
required  for  Types  Cl  and  C2  and  no  JIA-specific  server  specification  is  required.  Both  types 
are  considered  pure  encapsulated-object  types;  however  for  Type  Cl,  the  component  part  of  the 
object  can  be  implied  (i.e.,  omitted),  as  its  presence  can  be  assumed  as  preinstalled  on  any  JIA- 
compliant  browser  and  need  not  be  included  in  the  transported  lETM  view  package. 

The  Type  Cl  definition  is  closely  tied  to  the  specific  versions  of  HTML  and  XML,  a  factor 
which  needs  further  clarification.  For  planning  purposes,  it  is  recommended  that  emerging 
standards  (and  not  current  standards)  for  both  HTML  and  XML  be  used  to  define  the  JIA 
requirement.  In  this  light,  HTMUXML  is  herein  specified  as  employing  both  HTML  version  4.0 
and  XML  version  1.0  (including  the  associated  XSL  style  and  XLL  linking  specifications),  when 
these  two  International  W3C  (World  Wide  Web  Consortium)  standards  are  formally  approved. 
HTML  4.0  is  a  mature  specification  and  should  soon  be  approved,  while  the  XML  family  of 
standards  is  still  a  year  or  two  away.  There  are  several  reasons  for  this  recommendation.  The 
future  standards  will  almost  certainly  be  relevant  in  the  time  frame  when  most  applications  are 
developed  according  to  the  proposed  architecture,  so  the  best  estimate  as  to  what  will  be 
applicable  should  be  used.  Vendor  implementations  of  the  draft  standards  are  available  now  for 
test  purposes. 
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Another  important  consideration  is  that  there  has  been  written  commitment  by  many  major 
software  vendors  to  support  future  standards,  whereas  there  is  no  complete  agreement  on  the 
delivered-product  support  of  the  current  standard  (i.e.,  HTML  3.2).  In  particular,  vendors  have 
indicated  support  of  the  emerging  HTML  4.0  standard.  Additionally  the  XML  standard  has 
elicited  widespread  vendor  promise  of  support  as  a  user-extensible  expansion  of  HTML.  XML 
lags  behind  HTML  4.0  in  maturity,  but  is  sufficiently  complete  so  that  prototype  software  exists 
from  major  vendors,  and  shows  promise  of  becoming  a  Web-based  tagging  standard  that  is  more 
suited  to  complex  lETMs  than  HTML.  In  particular,  it  will  be  much  easier  to  convert  the  large 
DoD  inventory  of  SGML-tagged  source  data  to  XML  for  a  runtime  object  than  it  is  to  convert  it 
to  HTML  for  presentation. 

For  Type  SI  and  S2  lETM  applications,  the  situation  for  ascertaining  de  facto  industry  practices 
is  much  more  complex.  Several  approaches  are  available  for  standardizing  many  issues  such  as 
Microsoft’s  design-time  controls.  Active  Server  Pages  (ASP),  and  Front  Page  server  extensions, 
and  a  variety  of  third-party  middle-ware  products;  but  they  are  all  proprietary  and  not  universally 
accepted.  The  technology  of  C/NDI  are  not  sufficiently  mature  at  this  time  to  propose  any  one  of 
them  as  a  DoD  standard  so  that  all  lETMs  can  operate  on  a  single  server.  There  are  two  possible 
approaches  for  a  working  solution  to  operational  interoperability  with  a  particular  server  in  the 
short  term: 

1.  The  various  lETM  providers  must  put  their  own  physical  server(s)  plus  the  lETM  view 
packages  on  the  shared  user  intranet.  This  is  very  feasible  with  the  state  of  the  art  and 
capacity  of  today's  portable  computers  and  plug-in  network  standards;  or 

2.  Require  that  all  lETM  creators  use  the  same  sets  of  server  components  and  that  the 
standard  components  be  installed  on  all  intranets  employed  in  the  community  throughout 
which  the  lETMs  are  interoperable.  However,  for  multi-service  operations,  this 
alternative  is  not  practical. 
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Table  7-1.  Proposed  lETM  Architecture  Types 


r  Type  1 

Characteristics 

Examples 

Typed:  I 
1  Basic  HTML/ 
XML  Pages 

1 

HTML/ XML  page(s)  with  only  browser-  | 

resident  components.  Requires  no  1 

component  licensing.  Most  will  work  on  any  1 
browser.  Includes  HTML  4.0  scripts.  1 

Client  processing  only.  “Basic”  HTTP  j 

server,  ■  J 

HTML  with  Java  script,  GIF, 
JPEG,  frames 

XML  +  XSL  Style  Sheets 

\ 

i 

1 

1  1 

Note:  HTMty  XML  pages  may  be  used  to  ! 
include  one  or  more  Type  C2  custom 
components.  If  the  HTML/XML  tags  no 
displayed  content,  it  is  considered  Type  C2. 

If  it  does  contain  tagged  data,  it  is  a 
combination  C1/C2. 

C1/C2  examples: 

HTML  file  plus  Java  “bean(s)” 
HTML  file  plus  plug-in 

HTML  file  plus  ActiveX 
control(s) 

type  Cir 

Simple 

Component 

One  data  set  plus  one  custom  automaticaily 
downloaded  non-HTML  component. 

.pdf  plus  Acrobat  reader 
control 

.doc  plus  WordView  control 

May  be  nested  Type  C2  data¬ 
set/component  pairs  (“encapsulated 
objects”).  First  component  loaded  into 
browser  shell/container  has  capability  to 
access  another  client  component  and 
associated  data  set  under  control  of  original 
component.  Requires  component  licensing. 
Not  recommended  for  new  applications. 
Client  processing  only.  Uses  “basic”  HTTP 
server.  .  . 

Legacy  systems 
reprogrammed  as  custom 
browser  or  presentation 
system  operating  inside  a 
standard  browser 
shell/container. 

1  type  SI: 

HTML  Plus 

1  Application 

I  Server 

i 

1 

I 

{ 

"fwo^tier  architecture  in  which  Web  page 

I  includes  reference  to  server  application (s), 

I  which  must  operate  before  page  is 
delivered  to  client  as  Type  2  HTML/  XML. 
Data  and  components  managed  on  server. 
May  utilize  database  collocated  on  server, 

I  but  most  content  is  in  Web  page  files. 

Requires  HTTP  server  with  components  for 

I  server-side  computations.  Requires  client 

I  and  server  processing. 

MS  Front  Page  Webs 

MS  Design-time  Controls 

CGI  Server  Apps 

DynaWeb 

I 

. "jypg'^r"  ’ 

HTML  with 
Database 
Server 

1 

1 

,  _ree-~ier  afg^itgcture  that  includes  a  Web 

I  page  server  with  pages  functioning  like  a 

I  template:  e.g.,  for  calls  to  a  database, 
which  contains  most  of  the  lETM  content. 
Can  include  server  and  components  for 
custom  functions.  Requires  a  database 
Server  (e.g.,  Oracle)  in  addition  to  the  HTTP 
server.  Can  use  MIL-PRF-87269  Data 
model  for  database  on  server. 

I  Permits  both  Client  and  Server  processing. 

AIMSS  4.0  (planned) 

I  GD  TechSightWeb 

I  MS  ASP  w/ODBC  Calls 

,| 

7.13  Elements  Diagrams  for  Architecture  Types 

The  core  Architecture  (Types  Cl  and  Cl)  requires  two  kinds  of  software  elements:  client 
browsers  and  Web  servers,  as  illustrated  in  Figure  7-2.  In  general  these  are  hosted  on  separate 
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devices  connected  by  a  TCP/IP  network.  However,  an  intranet  can  also  be  set  up  in  a  single 
display  device  without  a  network.  In  the  case  of  lETM  Architecture  Types  Cl  and  C2,  these  two 
kinds  of  elements  are  all  that  is  needed.  In  the  case  of  Type  SI  (Figure  7-3),  a  requirement  exists 
for  an  additional  element,  the  application  server,  sometimes  referred  to  as  a  Web  server 
extension,  since  it  effectively  operates  in  the  same  operating  system  as,  and  is  an  extension  of, 
the  HTTP  server.  In  the  case  of  Architecture  TypeS2  (Figure  7-4),  there  is  the  additional 
requirement  for  a  database  server  which  hosts  most  of  the  lETM  content,  which  may  or  may  not 
be  hosted  in  the  same  device  as  the  Web  server.  A  Type  S2  application  usually  includes  aspects 
of  a  Type  SI,  since  it  requires  an  application  server  to  process  the  data  access  and  request  dialog 
between  the  Web  server  and  the  separate  database  server.  Note  that  while  the  line  between  these 
two  types  may  not  be  clear,  in  general  they  differ  in  where  the  primary  data  content  is  stored 
(i.e.,  in  the  server  files  or  database  server). 


Request  Web  Object  via  URL 


Return  Web  Pages/Components 


Figure  7-2.  Elements  for  Architecture  Types  Cl  and  C2 
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Figure  7-3.  Elements  for  Architecture  Type  SI 


Figure  7-4.  Elements  for  Architecture  Type  S2 
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7.14  Pilot  Programs 


Each  of  the  services  selected  pilot  programs  to  test  the  JIA  goals  and  objectives  (Table  7-2)  The 
selection  encompassed  each  of  the  architecture  types  previously  described.  During  the  October 
1998  CALS  ’98  Expo  in  Long  Beach,  CA,  the  conceptual  JIA  was  successfully  demonstrated. 
The  pilot  programs  were  hyperlinked  to  demonstrate  that  regardless  of  architecture  type, 
authoring  system  or  service,  the  lETMs  could  be  viewed  using  a  Web  browser. 


Table  7-2.  JIA  Pilot  Programs 


Service 

Program 

Technology 

Demonstration 

Architecture 

Type 

;NAVY 

LM-2500 

SGML  to  HTML 

Type  Cl 

LINK- 16 

SGML  to  HTML 

Type  Cl /C2 

F-18 

Quill  to  Web-based 

Type  S2 

ATIS-AIR 

PDF  to  Web-based 

Type  C2 

NSSN  Library 

SGML  to  HTMIVXML 

Typed 

:USMC 

Diode  Test  Set 

PDF  to  Web-based 

Type  C2 

TAOM 

MediaLynk  to  Web-based 

Type  SI 

AAAV 

TechSight  to  Web-based 

Type  S2 

Sweep  Function  Generator 

PDF  to  Web-based 

Type  C2 

AirTorce 

MPTO 

PDF  to  Web-based 

Type  C2 

F-22 

Paper  study 

N/A 

Army 

PPS-5 

PDF  to  Web-based 

Type  C2 

EPLRS 

SGML  to  Web-based 

Type  SI 
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APPENDIX  A 

SGML,  HTML,  XML  AND  lETM  SOFTWARE 


A.l  Introduction 

Selecting  lETM  software  is  dependent  upon  many  factors,  but  mainly  upon  the  class  of  DBTM 
that  is  to  be  developed.  This  appendix  discusses  the  role  of  SGML  and  DTDs  (Document  Type 
Definition)  in  the  development  process  for  lETMs.  It  also  provides  information  on  software 
available  to  accomplish  an  BETM  development  program.  Discussion  of  software  products  in  this 
section  in  no  way  implies  endorsement  by  DoD. 

lETM  software  falls  into  four  distinct  categories: 

•  Development  and  editing  software 

•  Parsers  (an  application  that  checks  conformance  to  a  DTD) 

•  Display  or  viewing  software 

•  Data  management  software 

A.2  SGML 

In  1986,  the  SGML  became  an  ISO  standard  [ISO  8879,  Information  Processing  -  Text  and 
Office  Systems].  ISO  8879  defines  a  method  (set  of  rules)  and  a  “language”  for  document 
representation.  SGML  provides  a  formal  markup  procedure  used  to  “tag”  or  identify  elements  of 
document  text.  This  tagging  can  be  machine-processed  and  is  independent  of  system  and  output 
environments.  SGML  provides  the  grammar  and  syntax  rules  for  the  language  used  to  describe 
both  document  content  and  structure  regardless  of  the  type  of  document  or  the  nature  of 
document  text. 

A.2.1  Background 

SGML  became  the  format  for  delivery  of  technical  documentation  as  part  of  the  CALS  initiative 
in  the  mid-1980s.  All  DoD  technical  manuals  are  required  to  be  delivered  in  SGML  format 
according  to  a  Service's  DTD.  SGML  was  designed  to  provide  a  flexible,  yet  structured,  open 
approach  to  documentation  development  and  management.  Any  document,  including  technical 
documentation,  typically  contains  three  characteristics:  content,  presentation  and  structure.  Most 
commercially  available  word  processors,  and  to  a  lesser  extent  desktop  publishing  programs,  are 
categorized  as  WYSIWYG  (what-you-see-is-what-you-get)  programs.  Editors  and  authors  using 
these  programs  are  usually  more  concerned  with  the  presentation  of  the  content  than  with  the 
structure.  Many  authors  spend  inordinate  amounts  of  time  formatting  a  document  for  an 
aesthetically  pleasing  display  (usually  paper).  This  presents  a  problem  when  data  needs  to  be 
shared  across  the  enterprise.  But  it  is  inconsistent  because  various  authors  applied  their  own 
interpretation  of  "what  looks  good."  If  authors  could  spend  their  valuable  time  creating  content 
with  a  structurally  strong  guide  (or  template),  and  leave  the  presentation  of  the  content  up  to  a 
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predefined  style,  all  documents  conforming  to  the  template  could  share  elements  while 
maintaining  a  consistent  look  and  feel. 

The  underlying  philosophy  behind  the  CALS  initiative  is  to  have  many  different  authors 
(contractors),  creating  reusable  chunks  of  information  (technical  data),  according  to  a  standard 
set  of  structure  rules  (DTD),  to  share  across  the  enterprise  (DoD).  Formatting  of  the  resulting 
SGML  instance  is  accomplished  by  application  of  a  style  sheet(s)  permitting  output  of  the  data  to 
various  display  devices  (paper,  CD-ROM,  Web).  In 
short,  SGML  separates  a  document's  content  and 
presentation  from  its  structure.  Publishing  SGML 
for  electronic  display  is  typically  more  cost 
effective  than  publishing  on  paper. 

SGML  documents  can  be  visualized  as  a  series  of 
parent-child  relationships  residing  in  containers.  In 
the  military,  technical  manuals  are  structured  as 
indicated  in  Figure  A-1.  The  document  is  the  “root 
element”  —  and  also  the  “parent”  —  that  contains 
the  front  matter,  body  and  rear  matter  “child”  elements.  This  analogy  can  be  extended  to  the 
entire  manual,  resulting  in  the  visual  tree  structure  of  the  Body  element  shown  in  Figure  A-2. 
The  Chapter  elements  are  the  children  of  the  Body  element  and  also  contain  children  of  their 
own.  The  structure  of  Chapter  X  is  representative  of  the  structure  found  in  a  procedural 
(corrective  maintenance)  chapter  of  a  military  technical  manual.  Chapter  Y  reflects  a  general 
information  (description  of  operation)  chapter  and  Chapter  Z  is  indicative  of  an  IPB  chapter. 
Figure  A-2  is  a  simple  example  of  the  main  structural  elements  of  military  technical  manuals. 
Many  manuals  can  contain  sophisticated  structures  requiring  extensive  document  analysis  to 
completely  describe  the  parent-child  relationships. 

The  military  is  not  the  only  organization  to  adopt  SGML  as  a  standard  for  the  exchange  of 
technical  data.  Many  industries  have  recognized  the  benefits  SGML  provides  over  proprietary 
authoring  programs,  including: 


Document 

—  Front  Matter  (Foreword, 

Safety  Summary) 

—  Body  (Chapters,  Sections,  and 
Paragraphs) 

*—  Rear  Matter  (Appendices,  Glossary) 


Figure  A-1.  Military  Manual  Structure 


Industry 

Common  SGML  Reference 

Automotive 

J2008 

Airlines 

ATA 

Semiconductor 

Pinnacle  (PCIS) 

Financial 

EDGAR 

Literature 

Text  Encoding  Initiative  (TEI) 

Publishing 

AAP 

A.2.2  DTDs 

The  content  of  a  technical  manual  may  be  considered  unformatted  source  data.  In  order  for  the 
source  data  to  be  processed,  it  must  be  marked-up  (tagged)  in  some  way  with  respect  to  its 
structure  or  content.  The  tagging  rules  that  apply  to  standardized  technical  manuals  are  defined 
by  the  DTDs.  A  DTD  is  a  file  that  identifies  the  elements  within  an  SGML  tagged  manual,  as 
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well  as  the  hierarchical  relationship  between  the  elements.  Other  than  MIL-PRF-28001,  DTDs 
exist  for  a  number  of  military  specifications  as  represented  by  the  below  chart. 


An  example  of  the  partial  DTD  for  a  technical  manual  containing  a  Body  element  described  in 
Figure  A-2  is  as  follows; 


<!DOCTYPE  DOC  [ 

<! ELEMENT  doc  -  -  (front,  body,  rear)> 

<!ATTLIST  doc  secure  (uc | c | ts ) #REQUIRED> 

<! ELEMENT  body  -  -  (chapter+)> 

<! ELEMENT  chapter  -  -  (title,  section )> 

<! ELEMENT  section  -  -  (title,  paraO+)> 

<! ELEMENT  paraO  -  -  (title,  subparal,  figure,  table) 
<! ELEMENT  subparal  -  -  (para+) 

<! ELEMENT  para  -  -  (#PCDATA) 


]> 


The  actual  DTD  is  contained  within  the  open  “[“  and  close  “]”  square  brackets.  The  first  line 
<!DOCTYPE  DOC,  begins  the  document  type  definition,  and  indicates  the  DTD  will  be  defined 
for  documents  of  type  “DOC.”  The  <!ELEMENTS  statements  identify  what  structural  objects 
are  permitted  within  the  document  and  also  their  hierarchical  relationship.  The  <!ELEMENT 
doc  -  -  (front,  body,  rear)>  statement  identifies  doc  as  the  root  element  that  must  contain  a  front 
element,  a  body  element,  and  a  rear  element.  The  body  element  must  contain  one  or  more 
chapters,  which  must  contain  at  least  one  section.  Notice  the  addition  of  the  <!ATTLIST 
statement.  An  attribute  is  a  method  of  modifying  an  ELEMENT’S  SGML  tag.  In  this  example, 
the  doc  ELEMENT  has  an  attribute  “secure”  indicating  its  security  classification  status.  Our 
document  can  either  be  unclassified  (uc),  classified  (c),  or  top  secret  (ts).  While  some  attributes 
are  optional,  the  secure  attribute  on  the  doc  tag  is  required  (#REQUIRED).  Also  note  the  term 
#PCDATA  which  stands  for  parseable  character  data,  meaning  source  data  (text  and  characters). 


A.2.3  FOSIs  and  Stylesheets 

Publishing  tagged  instances  on  paper  relies  upon  Formatting  Output  Specification  Instances 
(FOSIs)  to  describe  the  format  or  how  the  printed  document  will  be  presented  on  paper.  FOSIs 
control  such  things  as  location  of  footer  information,  page  numbers,  headings,  font  size,  etc.,  on 
a  printed  page. 
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A  FOSI  is  merely  an  instance  of  a  DTD.  It  provides  specific  values,  chosen  from  the  options 
defined  in  the  MIL  SPEC,  for  formatting  the  SGML  document.  Multiple  FOSIs  for  the  same 
DTD  can  be  developed  to  produce  different  presentation  formats  for  the  same  instance.  By 
selecting  different  values  for  the  style  characteristics,  a  FOSI  may  be  developed  that  creates  a 
page-oriented  single  column  output  format  or  a  two-column  output  format. 

Electronic  publishing  of  tagged  instances  for  lETM  displays  generally  rely  on  application 
specific  style  sheets.  Within  a  style  sheet  authoring  environment,  an  lETM  developer  specifies 
the  formatting  characteristics,  such  as  font  size,  color,  space  before,  indentation,  etc.,  of  elements 
in  the  lETM.  Fortunately,  SGML  elements  can,  within  style  sheets,  possess  an  inheritance 
property.  This  means  that  if  the  lETM  author  desires  the  paraO  element  to  be  12  point,  left 
justified  and  arial  font,  all  children  of  paraO  (subpara  1,  steps,  etc.)  will  inherit  the  parent’s 
formatting  characteristics.  Style  sheet  formatting  typically  starts  at  the  root  element  and 
continues  through  to  the  lowest  level  of  the  SGML  tree  structure.  In  this  manner,  the  look  and 
feel  of  the  lETM  displayed  on  a  computer  monitor  is  developed.  Like  FOSIs,  multiple  style 
sheets  may  be  built  for  a  single  SGML  tagged  instance. 

A.3  SGML  and  HTML 

SGML  is  the  parent  language  of  the  Hypertext  Markup  Language  ,  the  popular  format  for 
developing  Web  pages  on  the  WWW.  Sometimes  referred  to  as  "SGML-lite"  or  "dumbed  down 
SGML,”  HTML  was  designed  to  be  easy  to  understand  and  therefore  to  be  used  by  the  general 
public.  The  HTML  DTD  contains  a  limited  number  of  available  elements  to  produce  a  Web 
page.  The  same  general  concept  of  structured  documentation  applies  to  HTML.  However, 
HTML  browsers  are  more  forgiving  in  the  presentation  of  an  HTML  tagged  document.  An 
example  of  an  HTML  document  is  as  follows: 

<!doctype  html  public  " -//w3c//dtd  html  4.0  transitional//en"> 

<htitil> 

<head> 

<meta  name=" GENERATOR"  content="Mozilla/4 . 5  [en]  (Win95;  I)  "  > 
</head> 

<body> 

<hl>HANDY's  has  Bikes  for  Sale ! </hl> 

<h2>Manufacturer :  Thrasher</h2> 

<h3>Model  -  The  Zoomer  2  Wheeler</h3> 

<p>We  have  a  <i>Monster  Bike</i>  sale  going  on!</p> 

<table  BORDER  > 

<tr> 

<td>Men</td><td>Women</td><td>Children</td> 

</tr> 

<tr>  . 

<td>$109 . 99</td><td>$105 . 99</td><td>$99 . 99</td> 

</tr> 

<tr> 

<td>$99 . 99</td><td>$89 . 99</td> 

</tr> 

</table> 
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</body> 

</html> 


In  this  simple  example,  the  HTML  document  structure  consists  of  <head>  and  <body>  elements. 
The  <H1>  is  the  first  level  heading;  similar  to  a  chapter  title  or  <paraO>  element  in  military 
SGML  documents.  The  three  column  table  structure  consists  of  rows  <tr>  and  table  data  <td>. 
Formatting  codes  <i>  can  be  added  to  emphasize  words  or  characters.  The  display  of  the 
individual  HTML  elements  is  interpreted  by  the  browser’s  built-in  style  sheet.  Rendering  of  the 
above  example  in  Internet  Explorer  yields  Figure  A-3. 


We  have  a  Monster  Bike  sale  going  onl 


'iMen 

Women 

ijChildren 

I|S109.99 

m05.99 

i$99.99  1 

PS99.99 

|$89.99 

;[$7^99  1 

Figure  A-3.  HTML  Display  Within  Internet  Explorer 


A.4  SGML  and  XML 

The  limitations  of  HTML  prompted  the  World  Wide  Web  Consortium  (W3C  [a  organization 
combining  a  mixture  of  industry  and  Government  experts])  to  proposed  a  more  definitive 
language  for  describing  Web  documents.  The  eXentsible  Markup  Language  (XML  version  1.0) 
was  accepted  in  1998  as  a  standard  by  the  W3C.  XML  is  only  in  its  infancy,  but  the  advantages 
of  using  XML  (versus  HTML)  to  describe  the  contents  of  a  document  are  readily  apparent.  XML 
is  an  example  of  content  tagging  versus  many  DTDs  that  implement  the  structure  tagging 
approach.  Compare  the  XML  example  shown  below  with  the  HTML  example  previously 
discussed. 

<?XML  version  1.0 "> 

<!DOCTYPE  bikes  SYSTEM  bikes . dtd> 

<bikes> 

<coinpany>HANDY' s  has  Bikes  for  Sale  !  </company> 
<manufacturer>Thrasher</manufacturer> 

<model>The  Zoomer  2  Wheeler</model> 

<announce>We  have  a  <i>Monster  Bike</i>  sale  going  on ! </announce> 
<bikeinfo> 

<biketype>Men</biketype> 

<biketype>Women</biketype> 

<biketype>Children</biketype> 

</bikeinfo> 
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<bikeprice> 

<regprice>$109 . 99</regprice> 

<regprice>$105 . 99</regprice> 

<regprice>$99 . 99</regprice> 

</bikeprice> 

<sale> 

<saleprice>$99 . 99</saleprice> 

<saleprice>$89 . 99</saleprice> 

<saleprice>$75 . 99</saleprice> 

</sale> 

</bikes> 

Notice  that  the  tags  describe  the  information  contained  between  the  tags.  The  XML  document 
inside  an  XML  capable  Web  browser  will  be  displayed  identically  to  the  HTML  document. 

A.5  SGML  and  PDF 

Before  the  explosion  in  popularity  of  the  WWW,  the  Adobe  Corporation  recognized  the  need  for 
electronic  documents  that  retained  the  look  and  feel  of  the  printed  version.  Also  highly  desirable 
was  a  platform  independent  file  with  powerful  hyperlinking  capabilities.  Utilizing  their 
Postscript  printing  language,  Adobe  developed  a  Portable  Document  Format  (PDF)  that  permits 
the  user  to  quickly  navigate  an  electronic  document  via  a  key  word  search,  hyperlinked  table  of 
contents,  or  by  clicking  on  "thumbnail"  images  of  electronic  pages  (see  Figure  A-4).  This 
capability  is  available  to  the  user  from  the  same  source  file  regardless  of  the  viewing  platform 
(PC,  Mac  or  Unix).  The  user  only  needs  to  have  installed  the  freely  distributable  Adobe  Acrobat 
Reader.  When  the  Internet  became  a  popular  distribution  medium  for  electronic  documents, 
Adobe  reconditioned  Acrobat  to  work  with  either  Microsoft's  Internet  Explorer  or  Netscape's 
Navigator.  This  permitted  thousands  of  pages  of  documents  already  in  PDF  format  to  be 
displayed  from  within  a  Web  browser  without  further  modification  (i.e.  converted  to  HTML). 
Since  most  word  processing  files  or  desktop  publishing  files  could  already  output  a  Postscript 
file,  it  gave  large  numbers  of  potential  Web  publishers  a  relatively  inexpensive  method  of 
converting  their  electronic  files  for  Web  display. 

Probably  the  greatest  advantage  PDF  has  over  SGML  is  its  simplicity.  Typically,  novice 
electronic  publishers  already  have  all  the  required  tools  installed  on  their  computer  and  can 
quickly  begin  developing  PDF.  SGML,  on  the  other  hand,  requires  specialized  software  tools  and 
has  a  steep  learning  curve  associated  with  DTDs,  the  concept  of  stmctured  documents,  and 
FOSIs.  Another  benefit  of  PDF  files,  is  the  fact  that  licensing  fees  are  not  required  for  viewing 
EETMs  delivered  in  PDF  format.  All  current  SGML  browsing  software  applications  have  a 
licensing  fee  associated  with  the  distribution  of  SGML  based  lETMs. 
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PDF  files,  however,  do  have  some  drawbacks.  Technically,  PDF  files  are  a  proprietary  format, 
Adobe's  Acrobat  Reader  is  the  only  application  that  can  view  a  PDF  file  while  maintaining 
internal  functionality.  The  PDF  file  itself  cannot  be  edited,  only  the  source  file  can  be  modified 
and  remade  into  a  PDF.  Adobe  is  addressing  these  issues  by  providing  updates  to  the 
functionality  of  the  Acrobat  Reader.  Acrobat  can  be  downloaded  at  www.adobe.com. 


A.6  Developing  and  Editing  Software  -  Class  II  and  III 
A.6.1  ASCII  Editors 

Since  SGML  is  an  ASCII  file,  any  text  editor  can  develop  or  modify  an  SGML  instance.  This 
approach  is  not  recommended  for  large  SGML  files  or  for  SGML  novices.  Those  authors 
unfamiliar  with  structured  documents  or  the  target  DTD  can  introduce  too  many  structural 
mistakes.  The  most  common  process  when  using  a  text  editor  is  to  edit  a  previously  developed 
instance,  run  the  SGML  through  a  parser,  then  correct  the  errors  until  the  instance  parses. 
Common  text  editors  include: 


•  Notepad 

•  Wordpad 
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•  Textpad 

•  Program  File  Editor  (PFE) 

•  Emacs 


•  Word 

•  WordPerfect 

A.6.2  ADEPT*Editor 

A  product  of  Arbortext  in  Ann  Arbor,  Michigan,  ADEPT  was  the  first  widely  distributed  SGML 
development/editor  software  program  on  the  market.  It  combined  the  ease  of  a  word  processing/ 
desktop  publishing  environment  with  a  SGML-tagging  environment.  ADEPT  is  an  SGML 
development  tool  and  not  an  lETM  development  program.  It  produces  SGML  that  can  be  used  as 
the  source  data  for  lETM  viewers.  An  ADEPT  session  (Figure  A-5)  typically  consists  of: 


Opening  a  new  Arbortext  document. 

Selecting  a  precompiled  DTD.  The  program  reads  the  DTD  and  stores  it  in  memory. 


pBBl 


0-m  ^  paraO 

i  n  title  DLMB  GENERAL  ‘ 

I  B -n  para . Tlue  folbwing  pare 

i  Un  ^  xref  ^1 

!  ^  subparal 

I  i  i-ip  title . 

i-  H]  emphasis . E 


i  -IH  para . Cooliiigairfor 

i  ;  Vvl 

i  ^  ^  ... 

R  -HI  ^  subpara  1j.  ^ 

!  e  atitte .  g. 

I  y-  M  ^  emphasis . F  ; 


i- -111  para . The  DLMB  iir  |||; 

B-Si  subparal 

I  . 

emphasis . F 


para . The  basic  oper  ||j:  j 


DLWIB  GENERAL  THEORY  OF  OPERATION. 

The  following  paragraphs  describe  operation  of  the  DLMB  as  shown  in  the  block 

diagram,  [xTef:  xr0fid"zQOO'1fQQ4  xidtvpe^igure  1 

FIGURE  1-4 

DLMB  Environmental  Control.  Cooling  air  for  the  DLMB  is  provided  by  the  aft 
avionics  forced  air  system,  which  cools  the  MSC  enclosure. 

Power  Input  and  Distribution. The  DLMB  interfaces  with  aircraft  equipment  to 
receive  1 15-volt,  400-Hert^  3-phase  primary  power.  Application  of  power  is 
controHed  by  signal  MARITIME  ENCLOSURE  TURN-ON  from  the  radar 
control  and  maintenance  panel  (RCMP).  CABINET  POWER  switch  SI  is  used 
to  interrupt  power  during  maintenance  of  the  units  within  the  MSC  enclosure. 

The  DLMB  bulk  supply  provides  UNRGLTD  DC  to  the  series  regulators,  which 
supply  +5.3  volts  to  the  DLMB  circuits. 

Functional  Interface  With  Other  Units.  The  basic  operation  of  the  DLMB  is 

controlled  and  monitored  by  the  RDP  via  data  comm  signals  CONTROL  DATA 


Figure  A-5.  Arbortext’s  ADEPT*Editor  Interface 
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•  Begin  developing  your  document. 

Whereas  an  inappropriate  element  could  be  introduced  at  any  point  within  the  SGML  by  a  text 
editor,  the  ADEPT  development  environment  permits  the  author  to  only  create  elements  that 
conform  to  the  structure  defined  by  the  DTD.  A  “quick  tag”  feature  displays  a  list  of  structural 
elements  that  can  be  created  at  a  particular  location  within  the  document. 

A  screen  FOSI  and  a  print  FOSI  (if  necessary),  conforming  to  the  target  DTD,  need  to  be 
developed  prior  to  authoring.  Fortunately,  many  of  the  Services  have  already  developed  these 
FOSIs  for  popular  DTDs.  The  graphical  user  interface  of  Arbortext  can  be  customized  using  a 
program  known  as  the  ADEPT  Command  Language  (ACL)  which  is  available  separately.  As 
long  as  a  document  conforms  to  the  DTD  loaded  into  memory,  ADEPT  will  accept  pre-tagged 
SGML  files.  ADEPT  will  parse  the  file  upon  loading  and  ADEPT  will  reject  the  file  if  errors  are 
encountered.  All  known  SGML  errors  should  be  corrected  before  importing  an  SGML-tagged 
file  into  ADEPT. 

A.6.3  FrameMaker+SGML  (FM+SGML) 

FM-i-SGML  is  an  Adobe  System  product  and  is  based  upon  their  popular  FrameMaker  desktop 
publishing  software.  FM+S^jML  is  an  SGML  development  tool  and  not  an  lETM  development 
program.  It  produces  SGML  that  can  be  used  as  the  source  data  for  lETM  viewers.  The 
FM+SGML  authoring  environment  (Figure  A-6)  provides  both  a  WYSIWYG  and  an  SGML 
view  of  the  data  during  author  and  edit.  The  approach  to  development  of  SGML  files  is  very 
similar  to  that  of  ADEPT.  Instead  of  FOSIs,  Adobe  substitutes  Electronic  Display  Definitions, 
read/write  rules  and  SGML  application  support  files.  Through  the  development  of  filters  and 
scripts,  FM+SGML  files  can  be  exported  to  HTML  and/or  PDF  for  Web  display.  FM+SGML 
treats  non-conforming  SGML  files  as  unstructured  documents.  SGML  construction  errors  can  be 
corrected  by  traversing  the  document  and  correcting  as  required. 
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. SECTION'Vil' . 

DLMB  FAULT  DETECTION  AND  CONFIGURATION  CONTROL! 


15.1  INTRODUCTION.1 

This  section  describes  how  faults  are  detected  in  digital 
^and  mass  blanker  (DLMB)  under  automatic  control  ! 

15.2  GENERAL.I 

jpauit  detection  for  tile  DLMB  is  accomplished  by  the  radar 
:data  processor  (RDP).  The  RDP  requests  response  data  dur¬ 
ing  every  slant,  analyzes  the  response  data  for  fault  indica- 
ilions,  and  stores  tiie  results.  DIME  fiiult  detectioii  is 
provided  by  the  contbuously  monitored  parameters 
^CMP).  All  DIME  GMPs  are  secondary  GMPs  that  do  not 
shut  down  the  radar  system.  If  a  fault  is  detected,  the  RDP 
[displays  a  message  on  the  radar  control  and  maintenance 
panel  (BCMP)  display.  Faults  tiiat  can  be  corrected  by 
reconfiguration  are  limited  to  tiie  failure  of  a  tiie  redundant 
portion  of  power  supply  regulators  4A3A25  and  4A3A26. 
There  arc  no  redundant  DLMB  circuits  switched  on-line  by 
[surveillance  radar  operational  pro^am  (SROP)  or  inter¬ 
changed  manually  during  fault  isolate  tests  (FIT).! 

15.3  FAULT  DETECTION  TESTS.! 

pLMB  faults  are  detected  by  automatic  fault  detect  test 
routines  of  the  SROP.  Faults  detected  but  not  corrected  by 


certain  bits  of  data  response  words  253, 254,  and  255  sent 
to  the  RDP  during  each  slant  DLMB  regulator  fault  detect 
data  is  also  contained  in  maritime  surveillance  capability 
(^G)  receiver  response  word  27.  (Refer  to  T.O,  1E-3A- 
43-2-93-3-10.)! 

B.3.2.2!| 

CMP  Fault.!! 

Ihe  RDP  compares  tile  CMP  values  with  established 
thresholds  and  stores  the  comparison  results.  A  CMP  fault 
is  declared  when  an  out-of-tolerance  condition  eidsts  for 
two  consecutive  slants,  "When  a  DLMB  CMP  fault  is 
declared,  the  RDP  automatically  records  fault  information 
and  takes  tile  following  actions:! 

?or  an  output  voltage  failure,  the  corresponding  DLMB 
redundant  series  regulator  is  switched  on-line.! 

?0T  failure  of  otiicr  DLMB  CMPs,  a  failure  message  is  dis¬ 
played  because  the  DLMB  does  not  have  redundant  units.! 

H 

A  message  is  displayed  on  the  RCMP  to  inform 
the  technician  of  units  switched,  the  existing  fault 

artinn  that  is , 


Figure  A-6.  FrameMaker+SGML  Authoring  Environment 


A.6.4  IADS 

The  Interactive  Authoring  and  Display  System  (IADS)  was  developed  at  the  Army’s  Redstone 
Arsenal  in  response  to  many  Army  Program  Manager’s  requests  for  an  lETM  viewing  software 
free  of  licensing  requirements.  IADS  also  releases  DoD  from  committing  to  any  one  proprietary 
method  of  displaying  lETMs.  It  uses  SGML  as  the  source  data  but  requires  the  data  to  be 
chunked,  or  separated  into  frames  of  logical  topics.  A  first  level  paragraph  can  be  a  frame,  table, 
or  figure.  The  frames  are  given  specific  ID  attributes  and  then  hyperlinked  based  on  the  ID  value. 
The  resulting  file  is  delivered  with  the  IADS  reader  to  view  (Figure  A-7)  on  a  standard  PC. 


I 
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ADMINISTRATIVE  STORAGE 


Eledronic  equipment  placed  in  administrative  storage  (1  to  45  days)  should  be  capable  of  being  ready  for  use  within  24  hours  or  as  required  by  local 
standard  operating  procedures  Before  placing  the  radar  set  in  administrative  storage,  perform  the  following; 

•  Preventive  maintenance  checks  and  services  on  page  3-51 

•  ComputertestfTM  11-5840-354-10-1) 

•  CPC  test  (TM  11-5840-354-10-1) 

•  Shelt0rfest(TM  1 1-5840-364-10-1) 

•  Treilertest(TM11-5840-354-10-1) 

•  Correct  all  known  deficiencies 

•  Apply  all  current  modification  orders 

•  Stow  all  items  and  secure  equipment  as  for  preparation  for  movement.  See  TM  1 1-5040-354-10-1 

Store  radar  set  in  the  best  available  site  for  storage  that  will  provide  protection  from  the  elements  and  from  unauthorired  personnel.  After  storing  the  radar 
set  conspicuously  mark  the  area  "Administrative  Storage." 
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:l;or  Hefp*  press  FI ; 


Figure  A-7.  IADS  Reader 


A.7  Developing  and  Editing  Soflvi^are  -  Class  IV 
A.7.1  TechSight 

The  TechSight  Developer’s  Kit  was  developed  for  the  Armed  Forces  as  a  MIL-PRF- 
87268/87269  compliant  authoring  program  that  provides  the  necessary  tools  to  create  Class  IV 
lETMs,  either  as  a  single  EETM  or  as  part  of  a  collection  of  documents  which  supports  cross 
referencing  and  data  object  sharing.  The  TechSight  database  structure  separates  information  by 
data  type  for  ease  of  maintenance  and  minimum  redundancy  of  common  objects.  Users  have 
complete  flexibility  in  authoring  tools  and  can  readily  transform  TechSight  data  to  other  DTDs 
or  formats  using  C/NDI  tools,  providing  data  portability  and  durability.  TechSight  integrates 
with  PM+SGML  to  provide  SGML  editing  features.  The  TechSight  Viewer  provides  the 
capability  to  view  hierarchical  illustrated  repair  parts,  navigate  procedures  with  complex 
branching,  and  link  to  integrated  training  modules.  It  also  permits  a  feature  which  automatically 
requires  the  user  to  log-in  upon  accessing  the  ITEM.  In  addition  to  the  normal  views  of  text, 
tables,  and  graphics,  TechSight  provides  a  procedure  execution  mode  that  can  be  authored  to 
show  procedures  (Figure  A-8)  either  as  step-by-step,  or  with  multiple  steps  shown  with  the 
active  step  highlighted.  The  table  viewer  supports  complex  tables  as  allowed  by  MIL-PRF- 
87269,  and  permits  the  replication  of  complex  tables  that  are  frequently  used  in  legacy 
documentation.  Within  a  single  lETM,  a  user  can  view  data  in  multiple  windows  simultaneously 
(e.g.  descriptive  text  in  one  window,  an  associated  graphic  in  another,  a  procedure  in  a  third,  and 
repair  part  sparing  and  ordering  information  in  another).  The  viewer  also  provides  full  navigation 
and  search  capabilities,  and  the  ability  to  include  notes,  bookmarks  and  directed  change 
notations.  General  Dynamics  developed  TechSight. 
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I  ^  fechSight 

3  Browse:  TM  9  2350  200  20  TANK.  COMBAT.  FULL  TC^CK...  HEiH 


"'§b  IS^ndow  Help, 


DRIVER'S  INTEGRATED  DISPLAY  (DID)  REPLACEMENT  - 
REMOVAL 


Sealing  compound 


i  ;AEX<001. 001  *600-90 


PERSONNEL:  Two 

EQUIPMENT  CONDITION:  Tank  power  disconnected  (ACS-OZS-OCI-OIO) 
Driver's  hatch  open  ((X!G-O0T-OO1 -FOO) 

Turret  traversed  so  main  gun  is  over  right  or  left  side  of  tank,  and  turret 
locked  (CO8-OO5-0O1-DOO) 

1 .  THIS  STEP  IS  ADDED  FOR  LYNNE  AND  JOHN. 

2.  REMOVE  THREE  HARNESS  CONNECTORS  (1)[PARTINFOjFROM 
RECEPTACLE  CONNECTORS  (2)[PARTlNFOj.[Vfdso] 


Display  (3)fPART!NFOj  weighs  49  pounds  (22  kg).  To  avoid  injury,  two 
soldiers  are  needed  to  remove  display  (3)[PARTINFO]. 

3.  REMOVE  DlSPLAYmXXX  CBjlPARTINFO]. 

a.  Remove  screw  (4)fPARnMF 01.  washer  (S)fPARTINFO|,  and 
electrical  lead  PfPARTINFOJ  from  display  (3)(PARTINFO]. 

b.  Remove  four  screws  (7)[PARTlNFO],  eight  washers  (6)|PARTtNFOj 
and  guard  ^jfPARTINFO]  from  display  (3)[PART1NFQ].  . Remove 
display  (3)1  PARTI NFO). 


H  t»  - 


Figure  A-8.  TechSight  Viewer 


A.7.2  Quill 

The  Quill^’  system  (Figure  A-9)  consists  of  an  authoring  system,  a  database,  and  presentation 
tool.  The  authoring  system  is  a  C++  X-Windows  application  that  populates  an  object-oriented 
database  (based  on  the  Versant  engine).  MIL-PRF-87269  compliant  SGML  is  generated  for  the 
object-oriented  database  and  parsed  into  a  relational  database  for  presentation.  The  presentation 
tool  is  a  cross-platform  application  that  displays  dynamically  constructed  panes  of  data.  All  user 
activity  through  the  lETM  is  captured  in  an  audit  log  that  can  be  downloaded  into  the  customer’s 
maintenance  network.  The  presentation  system  runs  on  the  Windows  95/NT,  SCO  Unix,  Solaris 
and  HP  operating  systems  using  Oracle,  Informix  or  Sybase  relational  database  management 
systems.  Boeing  developed  Quill^'. 
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Figure  A-9.  Quill^*  System 


A.7.3  Advanced  Integrated  Maintenance  Support  System  (AIMSS) 

AIMSS  is  a  Windows-based  product  that  combines  an  lETM  with  state-of-the-art  object  database 
technology.  AIMSS  uses  a  common  graphical  user  interface  to  display  maintenance  information 
in  text,  graphics,  and  table  windows  that  can  be  easily  manipulated  by  the  technician  for 
preferred  viewing.  Hypertext  and  graphic  “hot  spots”  are  embedded  in  descriptions  and 
procedures  to  provide  rapid  access  to  related  information  contained  in  the  database.  For 
example,  while  viewing  a  fault  isolation  procedure,  the  technician  is  provided  direct  access  to 
related  information  such  as  schematics  and  parts  lists  by  way  of  links  that  are  embedded  in  the 
text  of  the  procedure  and  its  associated  graphics. 

One  of  the  most  powerful  features  of  the  system  is  its  fault  isolation  capability.  The 
troubleshooting  approach  used  is  much  like  the  traditional  fault  logic  diagrams  provided  in 
technical  documentation.  However,  AIMSS  eliminates  the  navigation  problems  sometimes 
experienced  with  lengthy  flow  diagrams. 
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Troubleshooting  information  is  presented  in  a  linear  step-by-step  fashion  to  the  technician.  Each 
step  contains  detailed  instractions  and  a  question  requiring  a  simple  “yes/no”  answer  or  a  type-in 
response.  The  system  then  either  branches  directly  to  the  next  step  on  “yes/no”  responses  or 
performs  an  arithmetic  operation  on  the  technician’s  type-in  response  to  determine  the  next  step 
to  be  displayed.  Using  a  combination  of  “yes/no”  answers,  type-in  responses,  and  arithmetic 
operations,  AIMSS  can  simplify  complicated  procedures  (Figure  A-10). 
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Loosen  22  captive  screws  and  back  out  until  threads  of 
screws  eng^ige  threads  In  interface  module;  then  carefully 
lilt  interface  moduie  front  while  observing  connectors  until 
they  separate. 

Remove  Interface  module  out  from  BHU  enclosure  In 
direction  shown  to  avoid  damage  to  enclosure  guide  pins. 
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CAUTION 

Damage  to  connectors  and  enclosure  guide  pins 
can  result  if  care  is  not  observed  when  removing 
Interace  module  from  BHU. 
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Figure  A-10.  AIMSS  Viewer 

A.7.4  Joint  Integrated  Maintenance  Information  System  (JIMIS) 

JIMIS  is  also  an  object  oriented  database  capable  of  producing  MIL-PRF-87269  compliant 
lETMs.  Currently  deployed  in  the  Joint  Surveillance  Target  Attack  Radar  System  (JSTARS) 
community,  JIMIS  (Figure  A-1 1)  is  also  being  used  for  lETM  development  in  the  V-22  Osprey 
Helicopter  program.  Technical  data  for  the  entire  aircraft  is  stored  on  a  ruggedized  laptop 
computer.  Fault  codes  supplied  to  the  maintenance  chief  by  the  flight  crew  are  imported  to  the 
lETM  as  an  identifier  to  rapidly  access  the  appropriate  location  of  the  lETM  and  resolve  the 
problem  quickly  and  efficiently.  A  program  running  in  the  background  records  each  keystroke 
and  time  to  perform  procedural  steps.  The  output  data  from  the  recording  program  can  be  used  to 
update  Mean  Time  To  Repair  (MTTR)  parameters  and  provide  updated  statistical  information 
on  Mean  Time  Between  Failure  (MTBF)  for  parts/equipment.  The  JSTARS  Web  page  is 
accessible  at  http://www.jimis.Jstars.af.mil.  Northrup  Grumman  developed  JIMIS. 
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Figure  A-11.  JIMIS  Screens 


A.8  Parsers 

A  parser  is  a  software  application  capable  of  analyzing  the  structure  of  a  document.  Two  input 
files  are  required  for  a  parser  to  validate  a  document:  the  SGML  instance  itself  and  the  DTD.  A 
parser  will  check  the  tree  structure  and  permitted  elements  from  a  DTD  against  the  tree  structure 
and  elements  of  an  SGML  instance.  Some  parsers  will  check  the  entire  instance  and  produce  an 
output  error  file.  The  error  file  will  contain  information  about  the  line  number  on  which  the 
SGML  error  occurred  and  why  it  was  an  error.  Other  parsers  will  exit  upon  encountering  the  first 
SGML  error,  requiring  the  user  to  repeatedly  parse  and  correct. 

Some  parsers  are  pre-packaged  with  an  application  (such  as  ADEPT),  while  others  are  free.  The 
two  most  popular  parsers  are  SP  and  Omnimark;  others  are  also  presented  below. 

A.8.1  SP 

This  is  a  free  parser  and  toolkit.  SP  contains  a  parser;  nsgmls  and  two  SGML  normalizers;  SP 
Added  Markup  (SPAM)  and  sgmlnorm.  The  normalizer  is  an  application  that  takes  SGML  input 
and  substitutes  all  the  proper  entities  enabling  a  formatter  to  produce  a  complete  SGML 
document.  SP  is  written  in  C++  and  is  available  for  many  types  of  Unix,  MS-DOS,  and  Windows 
95/NT  platforms.  It  can  be  downloaded  at  www.jclark.com/sp. 

A.8.2  Omnimark 

Although  mainly  used  as  a  parser.  Omnimark  can  also  be  used  for  pattern  recognition,  hypertext 
processing  and  converting  other  file  formats  (RTF,  ASCII)  to  SGML.  Omnimark  understands 
structured  documents  and  employs  a  sophisticated  pattern  matching  language  which  permits  easy 
identification  of  character  and  text  strings  to  marked-up  data.  Conversion  utilities,  rules  and 
script  development  within  Omnimark  allow  fast  translation  between  DTDs  and  instances  (i.e. 
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SGML  to  HTML).  Although  the  full  version  is  costly,  Omnimark  offers  a  Limited  Edition  (LE) 
version  for  developers  to  utilize  for  familiarization  in  developing  Omnimark  scripts.  OMLE  can 
be  downloaded  at  www.omnimark.com. 

A.9  lETM  Viewing  Software 

Note:  All  Class  IV  lETM  development  software  is  delivered  with  its  own  viewing  software.  Class 
IV  viewers  can  only  read  their  databases  and  cannot  be  used  to  view  a  different  database. 

Displaying  SGML  files  with  a  simple  text  editor  is  not  recommended  for  the  SGML  novice. 
Users  would  quickly  become  annoyed  at  viewing  tags  and  marked  up  documents.  A  reader  or 
browser,  is  needed  to  interpret  and  display  the  SGML  instance  as  well  as  provide  the 
functionality  offered  by  the  SGML.  Functionality  can  include  hyperlinked  references  (i.e.,  ''see 
Table  ...”),  full  word/phrase  search  and  quick  navigation  of  document  elements  (figures, 
paragraphs,  etc.). 

A.9.1  Advanced  Technical  Information  System  (AXIS) 

AXIS  is  the  Navy’s  document  and  library  management  software  installed  on  many  surface 
combatants  and  shore-based  facilities.  It  includes  a  graphic  viewer  to  display  raster-scanned 
technical  manuals  compliant  with  NIRS/NIFF  (Class  I  lETM).  Documents  are  intelligently 
indexed  to  include  hyperlinked  table  of  contents,  list  of  figures,  and  list  of  tables.  The 
presentation  is  page  oriented  and  can  be  printed  directly.  The  library  management  software  is 
also  capable  of  indexing  Class  IFIII  lETMs  and  digitized  engineering  drawings. 

A.9.2  Acrobat 

Acrobat  is  the  freely  distributed  PDF  viewing  software  (Figure  A- 12)  from  Adobe  Systems.  PDF 
files  retain  their  page  orientation  and  can  also  be  hyperlinked.  When  a  PDF  has  been  internally 
hyperlinked  via  an  indexing  process,  the  resulting  file  is  known  as  ‘Indexed”  PDF  (IPDF). 
Acrobat  cannot  be  used  to  view  SGML  documents.  Acrobat  is  used  by  all  the  services  for 
displaying  various  types  of  technical  data; 
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Figure  A-12.  Acrobat  Viewer 


A.9.3  InfoAccess  (lA) 


Also  known  as  Owl  or  Guide,  lA  was  one  of  the  first  commercially  developed  hypertext 
programs  to  be  used  by  DoD.  It  can  accept  structured  languages  (HTML,  SGML)  and  convert 
them  to  LA’s  Hypertext  Markup  Language  (HML,  not  HTML).  Formatting  styles  are  applied  to 
the  HML  document  for  presentation  and  display  (Figure  A-13)  of  lETMs.  lA  is  used  extensively 
by  the  submarine  community  for  displaying  lETMs.  The  user  interface  can  be  customized  using 
built-in  tools  within  the  Guide  Professional  Publisher  suite. 
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Technician  Name:  Smitty 

Ships  class:  Arleigh  Burke  Class  (DDG)  Destroyer 

Technical  Manual:  LM3450  Engine  Repair  Procedures 


High  Pressure  Turbine 
Repair  Step  (1  of  3) 


Hold  the  feedback  lever  firmly, 
remove  the  bolt  and  nut  that  secures 
the  rod-end  bearing  to  the  feedback 
lever. 

Release  the  lever  slowly  and 
ajlow  the  spring  tension  to  seat 
the  lever  against  the  internal 
stop.  Rerhove  the  aft  rod-end 
bearing,  locknut  and  cable 
retaining  nut  from  the  cable. 


Figure  A-13.  GUIDE  Reader  (InfoAccess) 


A.9.4  DynaText 

This  product  is  one  of  the  most  popular  SGML  browser  displaying  lETMs  within  DoD. 
DynaText  compiles  an  SGML  instance  into  an  electronic  book.  Style  sheets  add  functionality  to 
the  lETM  resulting  in  a  fully  hyperlinked  document  with  a  consistent  look  and  feel  (Figure  A- 
14).  Users  can  create  personalized  electronic  sticky  notes,  hyperlinks  and  bookmarks.  DynaText 
books  can  be  printed  in  whole,  or  in  chunks  based  on  containerized  SGML  elements.  With  the 
purchase  of  the  optional  System’s  Development  Kit,  the  DynaText  interface  can  be  tailored 
according  to  user  needs. 
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Chapter  1  Process  for  NSTM  Conversion 

■Riis  electronic  document  describes  the  processes  necessary  for  converting 
Interleaf  publishing  files  to  SGML-based  ETM  documents. 

Contents; 

Introduction 

Preparation  of  files 
Graphic  File  Creation 
Interleaf  to  SGML  Filters 
Remaining  Formatting 
Multimedia  Integration 
Quality  Assurance 
Completion 


Section  1  Introduction 
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Figure  A-14.  DynaText  Browser 


A.IO  SGML  Database  Managers 

One  of  the  early  benefits  noted  with  both  SGML  and  lETMs,  was  the  ability  to  share  and  reuse 
information  objects  both  internal  to  a  document  and  external  to  the  lETM.  For  example,  a 
specific  warning  is  repeated  ten  times  within  a  technical  manual  and  is  physically  recreated  in 
the  authoring  software  at  each  occurrence.  If  the  content  of  the  warning  was  modified,  it  was 
necessary  to  change  the  warning  ten  times.  Relational  database  managers  allow  an  author  to 
create  an  object  once  (a  warning  object)  and  establish  the  object’s  relation  to  other  technical  data 
in  the  manual.  When  the  object  is  modified,  it  is  changed  once  and  accessible  throughout  the 
document.  Although  the  warning  example  is  simplistic,  the  implications  for  storing  parts  data 
once  and  having  changes  reflected  throughout  an  entire  set  of  manuals  can  be  highly  desirable. 

Class  IV  programs  use  a  relational  database  as  the  engine  to  power  the  lETM  and  have 
information  reuse  capability.  Until  recently,  this  type  of  capability  could  not  be  extended  to  the 
Class  II  and  Class  III  level  lETMs.  It  is  important  to  note  the  following  software  products  do  not 
produce  an  MIL-PRF-87269  compliant  database,  nor  is  the  database  delivered  with  the  lETM. 
The  Class  II  and  Class  III  viewing  software  programs  previously  described  are  still  required  to 
be  packaged  with  the  SGML  source  data  contained  in  the  database.  These  products  are  SGML 
managers  and  provide  the  Class  lEIII  lETM  Life-cycle  Manager  with  a  tool  to  reap  the  benefits 
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of  information  object  reuse.  They  can  also  manage  the  data  with  SGML  editors,  export  SGML 
for  electronic  distribution,  or  forward  data  to  composition  engines  for  hard-copy  printing. 

The  Naval  Surface  Warfare  Center,  Philadelphia  and  Port  Hueneme  Divisions  use  the  Texcel 
Information  Manager  (IM).  IM  is  a  comprehensive  content  and  process  management  system  for 
creating  and  managing  SGML  and  non-SGML  documents.  lETM  authors  working 
simultaneously  can  use  IM's  collaborative  tools  to  find,  edit,  review,  reuse,  and  assemble 
information  managed  in  a  secure  database.  The  information  manager  establishes  a  collaborative 
environment  in  which  the  participants  in  the  lETM  life  cycle,  authors,  editors,  reviewers,  and 
subject  matter  experts  can  interact  with  each  other  as  well  as  with  the  document  database.  The 
integrated  workflow  system  (Figure  A- 15)  pushes  a  task  (and  its  associated  data)  to  the  correct 
user  and,  upon  completion,  instantly  notifies  those  assigned  to  the  next  step  in  the  process.  The 
Electronic  Review  tool  captures  the  electronic  comments  of  local  and  remote  reviewers,  which 
are  immediately  available  to  lETM  authors  and  editors.  SGML  objects  and  fragments  can  be 
checked  out  of  the  repository  for  off-line  editing.  When  the  object  is  checked-in,  it  is  parsed  to 
ensure  conformance  to  the  DTD. 
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APPENDIX  B 
CALS  PfflLOSOPHY 


B.l  Introduction 

Today's  environment  of  computer  technology  has  created  possibilities  for  information 
management  that  were  impossible  a  decade  ago.  The  computer  has  become  an  indispensable 
tool  in  the  creation,  handling,  and  management  of  technical  information.  In  order  to  capitalize 
on  this  fact,  DoD  and  industry  have  been  cooperating  in  a  joint  initiative  to  improve  weapon 
system  quality  and  reduce  costs  through  effective  application  of  computer  technology. 

B.2  Continuous  Acquisition  and  Life-cycle  Support  (CALS) 

This  Continuous  Acquisition  and  Life-cycle  Support  initiative,  formerly  Computer  Aided 
Logistics  Support,  was  designed  to  reduce  the  time  to  generate,  access,  manage,  maintain, 
distribute,  and  use  acquisition  and  logistics  support  data. 

CALS  is  a  DoD  and  industry  strategy  intended  to  enable  more  effective  generation,  exchange, 
management,  and  use  of  digital  data  supporting  defense  systems.  The  primary  goal  of  the  CALS 
strategy  is  to  migrate  from  manual,  paper-intensive  defense  system  operations  to  integrated, 
highly  automated  acquisition  and  support  processes.  Because  of  this  vision,  CALS  is  now 
recognized  as  a  facilitator  for  process  reengineering  globally  and  as  a  strategic  initiative  to 
enable  worldwide  integration.  The  CALS  initiative  includes  infrastructure  modernization  and 
standardization  for  the  exchange  of  digital  data.  The  integration  of  weapons  system  technical 
information  is  the  essence  of  the  CALS  concept  for  an  Integrated  Weapons  System  Database 
(IWSDB). 

CALS  sets  interchange  standards  for,  and  take 
advantage  of,  the  digital  data  revolution.  Other 
initiatives,  such  as  the  Integrated  Data 
Environment  (IDE),  have  been  introduced  to 
further  capitalize  on  the  ability  to  swap/transfer 
data  electronically  within  a  weapons 
development  program.  While  the  lETM  is  a 
CALS/IDE  product,  JCALS  provides  the 
architecture  and  a  series  of  management  tools  to 
facilitate  the  sustainment  of  lETM  deliverables 
and  other  digital  data  products.  As  is  noted  in 
Figure  B-1,  CALS  serves  as  the  overarching 
environment  within  which  the  lETM  is 
developed. 


Figure  B-1.  Digital  Product  Relationship 
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B.3  SECDEF  Policy 


A  29  June  1994  policy  memo  from  the  Secretary  of  Defense  initiated  action  to  migrate  away 
from  the  use  of  Government  specifications  and  standards  in  favor  of  performance  standards  and 
accepted  commercial  processes  and  practices,  where  applicable.  This  would  allow  DoD 
contractors  to  produce  less  costly  deliverables  that  provide  the  user  with  the  same  functional 
support. 

In  executing  the  policy,  the  DoD  has  reviewed  commercial  and  international  TM  format  and 
content  specifications  and  standards  with  the  goal  of  using  them  in  lieu  of  military  specifications 
and  standards;  none  were  found  to  be  complete  enough  for  use.  Commercial  and  international 
organizations  responsible  for  maintenance  of  these  documents  were  asked  to  adopt  certain 
military  specification  or  standards;  none  were  willing.  The  Core  CALS  Standards,  MIL-X- 
2800X  series  and  MIL-X-87268/87269  (addressed  later  in  this  chapter)  have  been  designated  as 
“performance”  standards  (MIL-PRF-2800X)  and  can  now  be  used  in  any  contractual  process. 
Those  specifications  and  standards  not  specifically  listed  on  the  DoD  Index  of  Specifications  and 
Standards  (DoDISS)  as  “performance  specifications  and  standards”  will  require  a  waiver  for  use 
in  the  contractual  process. 

B.4  DOD  Instructions 

DoD  5000.2-R  directs  the  application  of  CALS  to  new  defense  system  acquisitions  and  provides 
a  basis  for  applying  CALS  to  existing  defense  systems.  Implementing  CALS  policy  requires  a 
new  acquisition  strategy  to  plan  and  contract  for  defense  systems.  Requirements  for  CALS 
should  be  incorporated  in  defense  system  program  plans,  the  appropriate  sections  of  RFP  or  the 
Acquisition  Requirements  Package,  and  the  subsequent  contract.  CALS  implementation  requires 
a  significant  upgrade  in  the  DoD  infrastructure.  DoD  components  are  building  this  infrastructure 
to  acquire,  exchange,  and  use  digital  data  deliverables  and  will  continue  to  expand  the  ability  to 
receive,  store,  manage  and  distribute  digitized  technical  data. 

B.4.1  Planning 

Defense  Federal  Acquisition  Regulation  Supplement  (DFARS)  Part  207.105  requires  acquisition 
managers  to  describe  the  extent  of  CALS  implementation  in  their  acquisition  plans.  These  plans 
establish  the  framework  for  effective  implementation  of  the  CALS  strategy  by  identifying  system 
and  infrastructure  requirements. 

B.4.2  Solicitations 

DoD  5000.2-R,  released  15  March  1996,  established  a  core  of  fundamental  policies  and 
procedures  to  implement  various  engineering,  manufacturing,  and  support  disciplines.  Paragraph 
3.3.4.5,  “Continuous  Acquisition  and  Life-cycle  Support,”  states; 

Beginning  in  FY  '97,  all  new  contracts  shall  require  on-line  access  to,  or  delivery  of,  their 
programmatic  and  technical  data  in  digital  form,  unless  analysis  shows  that  life-cycle  time  or 
life-cycle  costs  would  be  increased  by  doing  so.  Preference  shall  be  given  to  on-line  access  to 
contractor  developed  data  through  contractor  information  services  or  existing  information 
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technology  infrastructure  rather  than  data  delivery.  The  PM  shall  be  responsible  for 
establishing  a  data  management  system  and  appropriate  IDE  that  meets  the  data  requirements  of 
the  program  throughout  its  total  life  cycle.  MDAs  shall  assess  the  IDE  developed  to  enhance  the 
program  and  mitigate  long-term  costs  at  each  milestone  and  program  review.  In  the 
implementation  of  an  IDE,  independent  standards  setting  bodies'  data  formats  shall  take 
precedence  over  all  other  formats.  The  issue  of  data  formats  and  transaction  sets  shall  be 
independent  of  the  method  of  access  or  delivery.  Acquisition  strategies  and  plans  shall  describe 
the  extent  of  implementation  of  these  requirements  in  accordance  with  DEARS  207.105. 

Solicitations  shall  require  specific  proposals  for  an  IDE  to  support  systems  engineering  and 
logistics  activities.  The  PM  shall  ensure  compatibility  of  data  deliverables  with  existing  internal 
information  systems,  and  augment  such  systems  as  required  to  provide  timely  data  access  and 
distribution  consistent  with  DEARS  227  and  252. 

This  Regulation  hereby  authorizes  the  publication  of  DOD  5010.I2-M,  DoD  Technical  Data 
Management  Program,  and  DOD  50I0.12-L,  Acquisition  Management  Systems  Data 
Requirements  Control  List  (AM SDL),  which  list  the  data  item  descriptions  and  source  documents 
approved  for  use  in  acquisition.  Programs  electing  not  to  use  the  data  management  processes 
described  in  DOD  50I0.I2-M  must  find  other  ways  to  comply  with  Public  Law  104-13,  The 
Paperwork  Reduction  Act  of 1995. 

B.5  Infrastructure 

As  part  of  the  CALS  implementation,  the  program  office  must  ensure  that  recipients  of  digital 
data  have  the  capability  to  receive,  store,  and  maintain  the  data.  The  availability  of  this  required 
inffastmcture  is  a  key  consideration  in  implementing  the  CALS  strategy  for  any  given  program 
acquisition.  Deficiencies  in  the  Government  infrastructure  may  require  investments  by  the 
acquisition  management  team  to  effectively  implement  the  CALS  strategy.  Additional  lead  time 
must  be  considered  in  the  acquisition  planning  process. 

B.5.1  Existing  Defense  Systems 

Existing  defense  systems  should  exploit  opportunities  to  obtain  cost  savings  by  retrofitting 
digital  information  technology  into  their  programs.  Program  phase,  type,  size,  and  duration  are 
influencing  factors  in  implementing  CALS.  Infrastructure  modernization  and  process 
improvement  programs  must  look  to  opportunities  for  retrofitting  digital  information  technology 
into  existing  programs.  In  order  to  take  advantage  of  this  technology  in  existing  programs, 
legacy  data  conversion,  re-acquisition  of  technical  data  in  digital  formats,  and  re-authoring  data 
into  processable  data  files  may  be  required. 

B.6  JCALS 

The  DoD  CALS  infrastructure  program,  JCALS,  provides  an  Information  Management  System 
that  is  evolving  to  support  uniform  logistic,  acquisition,  engineering,  manufacturing, 
configuration  management,  materiel  management,  and  other  life-cycle  functional  processes.  The 
JCALS  open-system  architecture  will  implement  a  communications  and  computing  infrastructure 
based  on  CIM  (Corporate  Information  Management)  Technical  Reference  Model  standards.  The 
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system  will  provide  uniform  applications  and  services  to  implement  joint  functional  processes 
through  the  use  of  the  JCALS  workbench.  The  workbench  will  provide  a  uniform  human-user 
interface  and  will  give  transparent  access  to  all  data,  applications,  and  software  tools  available 
throughout  the  architecture.  The  system,  through  the  workbench,  will  provide  a  flexible 
workflow  management  capability,  tailored  to  suit  the  organizational  structure  of  the  Service, 
command,  or  workplace  while  ensuring  that  future  changes  can  be  accommodated  easily.  The 
Global  Data  Management  System  (GDMS)  and  the  Workflow  Manager  form  the  core  of  the 
JCALS  program  and  are  key  to  the  JCALS  and  Defense  Infrastructure  Initiative  (DII) 
Architectures.  In  addition  to  these  core  JCALS  applications,  activities  can  also  implement 
JCALS  Technical  Manual  development  and  management  application.  The  JCALS  open-system 
architecture  will  be  scalable  to  allow  growth  in  scope,  size,  functionality,  and  processing  speed. 
This  will  be  accomplished  via  adherence  to  open  systems  standards,  and  through  modular 
hardware  and  data-driven  modular  software  design. 

Although  the  current  JCALS  design  does  not  include  an  application  for  development  of  the 
databases  that  are  the  core  of  the  higher  lETM  classes,  its  SGML  editor  does  allow  creation  of 
Class  II  and  III  lETMs.  With  its  rapidly  growing  deployment  throughout  the  Services,  JCALS 
can  play  an  important  part  in  many  programs’  technical  manual  development  and  management 
strategies.  This  is  especially  true  in  the  Air  Force,  whose  lETM  strategy  includes  extensive  use 
of  JCALS  as  its  primary  TM  creation  and  revision  system.  JCALS  technical  manual  capabilities 
are  described  in  the  following  paragraphs. 

B.6.1  TM  System  Functions 

The  JCALS  TM  processes  are  a  collection  of  services  that  ensure  control  and  standardization  of 
the  major  TM  system  functions:  manage,  acquire,  improve,  publish,  stock,  and  distribute.  These 
functions  include  managing  policy  and  guidance,  providing  program  support,  controlling  TM 
numbering  and  indexing,  and  managing  TM  publication,  stocking,  and  distribution. 

B.6.1.1  Manage 

The  Manage  TM  System  requirements  ensure  control  and  standardization  of  the  major  TM 
system  functions:  management,  acquisition,  maintenance/improvement,  publication,  stocking, 
and  distribution.  Within  the  TM  management  process,  managers  at  all  levels  are  involved  with 
the  planning,  scheduling,  development,  controlling,  and  budgeting  of  TMs. 

Requirements  to  satisfy  the  function  of  managing  TMs  will  he  fulfilled  in  large  part  by  the 
JCALS  Infrastructure  Work  Management  and  Information  Management  functions.  There  are 
four  sub-functions  within  Manage  TM  Systems: 

•  Manage  Policy  and  Guidance 

•  Provide  Program  Support 

•  Control  Publication  Numbering  and  Indexes 

•  Manage  TM  Repository 
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B.6.1.2  Acquire 

In  the  Acquire  TMs  functions,  the  user  identifies  TM  requirements  for  specific  equipment 
acquisition,  develops  TM  planning  documents,  drafts  TM  Contract  Data  Requirements  List 
(CDRL)  requirements,  and  incorporates  planning  documents  and  data  into  TM 
acquisition/management  plans.  The  Acquire  TMs  function  consists  of  developing  planning 
documents  for  the  TM  acquisition  process,  controlling  the  TM  acquisition  process,  and 
developing  TM  processes. 

B.6.1.3  Improve 

TM  improvement  refers  to  the  correction  or  enhancement  of  a  TM  due  to  errors,  problems,  or 
system/equipment  modifications  that  occur  during  the  life  cycle  of  a  weapons  system.  These 
activities  could  include  the  receipt  and  evaluation  of  a  recommended  change  due  to  a  perceived 
deficiency,  as  well  as  the  analysis,  content,  coordination,  approval,  processing,  and  control  of 
TM  improvement. 

B.6.1.4  Publish 

In  the  Publish  TMs  function,  the  change  pages  and/or  TM  pages  developed  in  previous 
publications  are  used  to  develop  draft  and  final  reproducible  masters  that  are  then  used  to  publish 
the  TMs  or  change  pages  for  distribution  and/or  storage.  Publishing  a  TM  includes  the  activities 
required  to  ensure  the  quality  of  the  published  document.  The  Publish  TMs  function  is  divided 
into  four  processes: 

•  The  development  of  a  reproducible  master 

•  The  preparation  of  a  reproduction  package 

•  The  reproduction  of  a  TM 

•  The  control  of  the  reproduction  material.  The  current  contractor  is  responsible  for  the  first 
process. 

B.6.1.5  Stock 

Stock  TM  refers  to  the  online  management  of  all  activities  associated  with  the  receipt,  storage, 
and  maintenance  of  the  TMs  and  records  associated  with  TM  inventory.  In  the  Stock  TMs 
function,  information  concerning  publications  received  from  a  reproduction  facility  is  inputted  to 
JCALS  at  the  stock  point.  Updates  concerning  stock  status  are  provided  from  the  stock  point 
JCALS  site  as  an  element  of  the  program’s  database.  Standardized  Stock  Status  reports  are 
generated  according  to  the  Service's  requirements. 
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B.6.1.6  Distribute 


Distribute  refers  to  the  activities  associated  with  the  tracking  of  requests  for  TMs;  initial 
identification  of  requirements,  distribution,  or  allocation  of  the  TMs;  changes  and  revisions;  re¬ 
supply;  and  the  routing  of  all  basic  manuals  and  changes  to  a  storage  location.  In  the  Distribute 
TMs  function,  TM  accounts  are  created  and  TM  distribution  requirements  are  established. 

B.7  TM  Process  Functions 

The  JCALS  TM  System  performs  the  following  TM  process  functions: 

•  Manage  Policy  and  Guidance 

•  Manage  TM  Numbering 

•  Manage  TM  Index 

•  Generate  TM  Index  Reports 

•  Manage  Quality  Assurance 

•  Improve  TM 

•  Manage  Program  Support 

•  Manage  Repository 

•  Perform  Acquisition 

•  Develop  TM  Reproducible  Master 

•  Reproduce  TM 

•  Manage  Inventory 

•  Manage  TM  Accounts 

•  Manage  Initial  Distribution  for  a  TM 

•  Manage  Initial  Distribution  for  a  TM  Account 

•  Manage  One-Time  Requisition 

•  Clear  TM  Exception  Transactions 

•  Perform  Post  Publication  Review 

•  Manage  TM  Pricing 
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B.8  Common  lETM  Standards 


CALS  standards  and  specifications  are  geared  toward  technical  data  interchange  requirements. 
The  documents  listed  below  are  CALS  standards  that  apply  to  lETM  acquisition  and 
development  and  serve  as  controls  to  ensure  that  information  systems  are  independent  of 
hardware  platform  and  proprietary  data  format. 

B.8.1  Document  Interchange  Standards 

B.8.1.1  MIL-STD-1840,  Automated  Interchange  of  Technical  Information 

MIL-STD-1840  is  the  interface  standard  which  defines  the  means  for  exchanging  large  quantities 
of  engineering  and  technical  support  data  among  heterogeneous  computer  systems.  MIL-STD- 
1840  is  often  called  the  "parent"  or  "umbrella"  standard  for  CALS,  because  it  identifies  other 
standards,  specifications,  and  practices  to  be  used  in  a  CALS  solution.  It  applies  selected  Federal, 
DoD,  International,  National,  and  Internet  standards/specifications/practices  for  the  exchange  of 
digital  information  between  organizations  or  systems  and  for  the  conduct  of  business  by 
electronic  means. 

The  initial  areas  addressed  by  MIL-STD-1840  involved  automating  the  creation,  storage, 
retrieval,  and  delivery  of  technical  manuals  and  engineering  drawings.  The  standard  defines  a 
logical  file  identification  and  bundling  convention  for  device  and  medium-independent  transfer 
of  technical  information.  MIL-STD-1840  also  addresses  electronic  product  data,  packaging  of 
data  for  electronic  commerce,  and  electronic  product  data  technology.  Revision  C  of  the  standard 
adds  several  new  data  types,  provides  for  new  transfer  media  in  addition  to  9-track  tape,  and 
supports  increased  Information  Security  (INFOSEC)  capabilities  including  digital  signature  and 
encryption. 

This  standard  applies  to  technical  information  which  is  part  of  the  traditional  technical  data 
package  used  for  system  or  item  acquisition;  technical  information  used  to  design,  manufacture, 
field,  and  dispose  of  a  system  or  item;  and  the  technical  documentation  used  for  system  or  item 
support.  MIL-STD-1840  also  can  be  employed  for  information  exchange  applications;  its  use  is 
not  limited  to  technical  data  exchange  in  a  defense  acquisition  environment. 

B.8.1.2  MIL-PRF-28001,  Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  Text 

MIL-PRF-28001  is  the  performance  specification  which  defines  DoD  requirements  for  the 
application  of  the  Standard  Generalized  Markup  Language  [defined  by  ISO  8879,  Information 
Processing  -  Text  and  Office  Systems  -  Standard  Generalized  Markup  Language  (SGML)].  This 
specification  provides  a  mechanism  for  the  digital  interchange  of  technical  publications  and  other 
text  data.  MIL-PRF-28001  is  designed  to  facilitate  the  automated  storage,  retrieval,  interchange, 
and  processing  of  technical  documents  from  heterogeneous  computer  systems. 
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SGML  provides  the  ability  to  markup  (tag)  textual  data  in  a  manner  to  define  data  content  and 
document  structure.  SGML  is  the  basis  for  HyTime  and  for  HTML,  which  are  used  in  electronic 
presentation  (notably,  the  WWW).  SGML  evolved  from  a  mid-1960s  effort  for  an  electronic 
ability  to  format  printed  text.  SGML  is  described  in  more  detail  in  Chapter  3. 

MIL-PRF-28001  establishes  a  DoD  application  protocol  of  SGML  that  defines  the  following 
requirements  for  page-oriented  technical  documents  in  digital  form: 

•  Procedures  and  symbology  for  markup  of  unformatted  text  in  accordance  with  this  specific 
application  of  the  SGML. 

•  SGML  compatible  codes  that  will  support  encoding  of  a  technical  publication  to  specific 
format  requirements  applicable  to  technical  manuals. 

•  Output  processing  requirements  that  will  format  a  conforming  SGML  source  file  to  the  style 
and  format  requirements  of  the  appropriate  FOSI  based  on  the  Output  Specification  (OS). 
Revision  C  of  MIL-PRF-28001  introduces  a  Formatting  Presentation  Specification  Instance 
(FPSI)  as  an  OS  for  the  electronic  display  of  SGML  documents. 

Future  versions  of  MIL-PRF-28001  will  emphasize  the  document  content  rather  than  structure  to 
provide  more  content  tagging,  and  database  interfaces,  as  well  as  capabilities  for  hypertext 
constructs  and  applications. 

B.8.1.3  MIL-PRF-87268,  General  Content,  Style,  Format,  and  User  Interaction 
Requirements  for  Interactive  Electronic  Technical  Manuals 

This  was  the  first  in  a  series  of  documents  released  by  NSWC,  Carderock  in  an  attempt  to 
standardize  requirements  for  military  lETMs.  The  specification  contains  common  requirements 
for  the  general  content,  style,  format,  and  user  interaction  features  (GCSFUI  -  pronounced  gucks 
phooey),  which  are  required  for  lETMs.  This  specification  established  the  “look  and  feel”  and 
navigational  aspects  of  the  lETM  viewing  software.  Although  intentionally  broadly  written  to 
permit  increased  browser  functionality,  many  software  vendors  have  not  followed  MIL-PRF- 
87268,  developing  their  own  interpretation  of  the  specification  instead.  The  end  result  has  been  a 
variety  of  lETM  viewing  software  that  does  not  provide  a  common  look  and  feel  for  each 
equipment/system. 

B.8.1.4  MIL-PRF-87269,  Revisable  Database  for  Support  of  Interactive  Electronic 
Technical  Manuals 

This  specification  prescribes  the  requirements  for  an  Interactive  Electronic  Technical  Manual 
Database  (lETMDB)  to  be  constructed  by  a  weapon-system  contractor  for  the  purpose  of  an 
lETM.  The  requirements  cover  the  specification  for  the  lETMDB  and  are  intended  to  apply  to 
one  or  both  of  two  modes  as  specified  in  a  contract: 

•  The  interchange  format  for  the  database  to  be  delivered  to  the  Government:  or 
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•  The  structure  and  the  naming  of  the  elements  of  the  database  created  and  maintained  by 
the  contractor  for  purposes  of  creating  lETMs  that  are  in  turn  delivered  to  the 
Government. 

Mainly  applying  to  Class  IV  and  above  lETMs,  this  specification  suffered  the  same  fate  as  its 
sister  GCSFUI  specification.  The  intention  of  MIL-PRF-87269  was  to  specify  how  a  revisable 
database  of  technical  data  elements  could  be  constructed  to  permit  interchange  of  data  with  other 
MIL-PRF-87269  database  driven  lETMs.  However,  software  vendors  and  original  equipment 
manufacturers  applied  their  own  interpretation  of  MIL-PRF-87269  to  fit  their  own  program 
needs.  While  Class  IV  type  lETMs  have  provided  many  of  the  benefits  first  envisioned  by  lETM 
pioneers,  interchange  of  MIL-PRF-87269  databases  has  not  been  fully  realized. 

The  MIL-PRF-87269  specification  calls  out  two  layers  to  define  the  lETMDB;  the  generic  layer 
and  the  content  layer. 

B.8.1.4.1  lETMDB  Generic  Layer 

The  lETMDB  Generic  Layer  provides  mandatory  requirements  for  the  definition  of  lETMDB 
conforming  DTDs. 

The  Generic  Layer  is  not  a  DTD.  It  is  a  layer  of  constructs  that  can  be  used  by  any  DTD  and 
lETM  application  implemented  in  accordance  with  the  requirements  of  MIL-PRF-87269.  In  the 
Generic  Layer,  the  two  requirements  that  are  of  importance  to  the  acquisition  manager  are  the 
use  of  “Architectural  Forms”  and  the  required  SGML  element  types.  The  lETMDB  architectural 
forms  and  the  SGML  element  types  required  for  the  lETMDB  are  briefly  discussed  in  the 
following  sections. 

B.8.1.4.1.1  Architectural  Forms 

Architectural  forms  are  a  way  of  logically  describing  building  blocks  for  an  application  without 
constraining  the  application-specific  information  that  a  developer  might  need  to  add.  Only 
information  that  must  be  standardized  for  interoperability  is  defined  rigorously. 

Architectural  forms  enable  the  DTD  designer  to  rapidly  create  a  legal  and  safe  "blueprint"  or 
template  for  the  hypermedia  application.  That  design  is  the  lETMDB  DTD.  Any  instance  of  that 
design  is  an  lETM. 

Just  as  standard  window  styles  and  sizes  are  used  by  an  architect  to  create  a  design  for  a  house, 
architectural  forms,  element  types  and  attribute  specification  lists  of  the  Generic  Layer  enable  an 
lETMDB  designer  to  create  a  content  layer  DTD  that  meets  the  needs  of  an  specific  lETM. 

B.8.1.4.1.2  Nodes 

Nodes  are  units  of  information  for  the  human  reader  or  for  the  lETM  presentation  system.  Some 
nodes  determine  order  or  presentation,  enable  the  selection  of  alternative  versions  of  the  same 
information,  or  set  criteria  for  deciding  if  and  how  many  times  a  unit  is  to  be  presented.  The 
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processing  system  or  the  user  may  use  a  unit  of  information.  Each  node  contains  information 
about  a  subject. 

B.8.1.4.1.3  Links 

The  relationships  among  nodes  are  expressed  both  through  the  hierarchy  of  the  nodes  as  declared 
in  the  DTD,  and  by  references  made  in  some  nodes  to  other  nodes.  These  references  are  called 
"links".  The  use  of  links  permits  alternative  organizations  of  the  information.  The  user  can 
traverse  the  information  in  different  orders  depending  on  the  type  of  link  and  sometimes 
conditions  that  must  be  met  before  that  information  is  presented. 

B.8.1.4.2  lETMDB  Organizational  Level  Content  Layer 

MIL-PRF-87269  uses  an  Organization  Level  (0-Level)  Technical  Manual  DTD  to  illustrate  the 
default  content  layer,  however  it  is  not  required  to  be  used  in  its  exact  form  in  order  to  produce  a 
conforming  lETMDB.  This  DTD  would  be  based  on  the  required  elements  of  the  generic  layer 
of  MIL-PRF-82769  and  would  provide  for  the  content  layer  of  the  lETMDB.  The  0-Level  DTD 
of  MIL-PRF-87269  could  be  used  as  a  guide,  but  specific  tailoring  will  be  required  by  each 
lETM  acquisition. 

B.8.2  Graphics  Interchange  Standards 

B.8.2.1  MIL-PRF-28002,  Requirements  for  Raster  Graphics  Representation  in  Binary 
Format 

MIL-PRF-28002  is  the  performance  specification  that  defines  DoD  requirements  for  the 
standardized  encoding  and  compression  of  raster  (bit-mapped)  image  data.  This  specification 
provides  for  the  digital  binary  representation  of  2D  bitonal  images  or  pictures  for  display  or 
interchange.  MIL-PRF-28002  also  defines  data  compression  to  reduce  file  size. 

In  Revision  C  of  the  MIL-PRF-28002  specification,  the  digital  representation  of  raster  data  is 
classified  as  the  following  four  types: 

•  Type  1,  Untiled  Raster  Data 

•  Type  2,  Tiled/Untiled  Raster  Data,  Office  Document  Architecture  (ODA)  Raster 
Document  Application  Profile  (DAP) 

•  Type  3,  Tiled/Untiled  Raster  Data,  Navy  Image  File  Format  (NIFF) 

•  Type  4,  Tiled  Raster  Data,  Joint  Engineering  Data  Management  Information  and  Control 
System  (JEDMICS)  C4 

Essentially,  MIL-PRF-28002  selected  a  popular  graphics  file  format,  the  Tagged  Information 
File  Format  (TIFF),  and  the  Navy  derivative  (NIFF),  as  the  required  graphics  format  for  scanned 
images.  Other  graphic  formats,  especially  those  containing  color  (GIF,  JPG,  BMP,  etc.),  have 
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surpassed  TIF  in  popularity.  However,  TIF  remains  the  preferred  graphics  file  format  for  black 
and  white  line  art  found  in  many  technical  publications. 

B.8.2.2  MIL-PRF-28003,  Digital  Representation  for  Communication  of  Illustration  Data: 
CGM  Application  Profile 

MIL-PRF-28003  is  the  performance  specification  which  establishes  the  DoD  requirements  for 
2D  picture  description  or  illustration  data  that  is  vector-based  (or  mixed  vector  and  raster).  MIL- 
PRF-28003  is  the  CALS  application  profile  of  the  Computer  Graphics  Metafile  (CGM),  as 
specified  by  the  Federal  Information  Processing  Standard,  FTPS  PUB  128. 

CGM  provides  a  standardized  electronic  format  for  the  capture,  storage,  retrieval,  transmission, 
and  interchange  of  2D  pictures,  independent  of  system  architecture,  device  capabilities,  or 
transmission  medium.  CGM  viewers  and  plug-ins  are  available  for  many  SGML  and  Web 
browsers  to  easily  view  2D  vector  data. 

Revision  B  of  MIL-PRF-28003  is  being  written  to  follow  closely  the  Air  Transport  Association 
(ATA)  application  protocol  for  CGM,  thereby  providing  a  bridge  for  the  interchange  of  2D 
vector  data  between  Government  and  private  industry. 

B.8.3  Product  Data  Interchange  Standards 

B.8.3.1  MIL-PRF-28000,  Digital  Representation  for  Communication  of  Product  Data: 
IGES  Application  Subsets  and  IGES  Application  Protocols 

MIL-PRF-28000  is  the  performance  specification,  which  defines  DoD  requirements  for  the 
application  of  the  Initial  Graphics  Exchange  Specification  (IGES).  This  specification  provides  a 
mechanism  for  the  digital  exchange  of  product  data  among  computer-aided  design  (CAD)  and 
computer  aided  manufacturing  (CAM)  systems.  This  specification  is  required  when  procuring 
three-dimensional  illustrations  (e.g.,  3-D  models,  wire  frames,  etc.) 

MIL-PRF-28000  applies  IGES  as  specified  by  the  U.S.  Product  Data  Association  (USPRO) 
standard.  It  defines  application  protocols,  or  "classes,”  which  are  subsets  of  the  IGES  entities 
identified  according  to  the  application  for  which  the  digital  data  was  prepared.  The  following 
IGES  classes  will  appear  in  Revision  B  of  MIL-PRF-28000: 

•  Class  1  -  Technical  Illustration  Subset 

•  Class  2  -  Engineering  Drawing  Subset 

•  Class  3  -  Electrical/Electronic  Applications  Subset  (Withdrawn) 

•  Class  4  -  Geometry  for  NC  Manufacturing  Subset 

•  Class  5  -  3D  Piping  Application  Protocol 

•  Class  6  -  Layered  Electric  Products  Application  Protocol 
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•  Class  7  -  3D  Geometry 


Most  SGML  browsers  cannot  view  IGES  illustrations  natively.  Therefore,  the  IGES  drawing  is 
typically  converted  to  a  CGM  format  (see  paragraph  B.8.5)  for  viewing  within  an  lETM 
application. 
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APPENDIX  C 

lETM  AND  TRAINING  STRATEGIES 

C.l  Introduction 

Today’s  military  budgets  demand  the  cost-effective  development  of  lETM  products  that  serve 
both  maintenance  and  training  requirements.  lETMs  are  a  key  source  of  data  to  implement  the 
electronic  classroom  and  on-the-job  training.  Training  benefits  from  lETMs  have  already  been 
demonstrated  through  practical  applications  in  several  programs.  Training  development  for  a 
system  is  a  long  and  complex  logistics  support  process  that  is  begun  early  in  system  acquisition. 
Clearly,  there  is  a  major  interface  between  development  of  training  and  the  development  of 
lETMs.  When  appropriate,  a  training  plan  (or  equivalent)  should  address  those  lETM  items 
needed  for  familiarization,  formal  classroom,  and  on-the-job  training  for  system  operation, 
maintenance,  and  other  special  forms  of  logistic  support.  To  identify  and  understand 
requirements  and  interfaces,  close  coordination  between  the  maintenance  planning,  technical 
manual,  and  training  disciplines  for  an  lETM  is  required.  In  order  to  determine  the  lETM 
functionality  needed  to  economically  support  training,  input  is  required  on  training  infrastructure 
requirements  and  its  objectives  to: 

•  Develop,  reduce  or  eliminate  formal  course  training 

•  Develop  on-site  training 

•  Define  and  develop  a  shared  lETM  and  training  database 

Once  the  equipment  and  user  training  requirements  are  determined,  all  disciplines  must  identify 
the  issues  and  resources  required  for  each  to  implement  the  lETM  within  their  community.  The 
Training  Plan  is  needed  prior  to  contract  award  to  permit  definition  of  EETM  features  needed  to 
support  the  training  requirements,  whether  in  a  formal  classroom  or  on-site. 

C,2  Integrated/Interfacing  Training  Strategies  and  Issues 

There  are  a  number  of  issues  involved  in  the  integration  of  electronic  versions  of  technical 
manual  data  (which  is  the  source  of  technical  data  for  training  materials)  and  automated, 
electronic  training  development  and  delivery  systems.  The  following  paragraphs  highlight  the 
selection  of  an  interface  strategy  and  other  issues  that  would  need  to  be  resolved  by  Program 
Managers  in  developing  logistic  support  for  a  system  or  equipment.  Due  to  the  rapid 
advancement  and  employment  of  automated  tools  to  create  and  present  technical  data,  failure  to 
address  these  issues  may  lead  to  early  problems  in  implementing  even  conventional  systems. 

C.2.1  Strategies 

There  are  four  strategies  for  approaching  the  interface  between  training  and  the  lETM 
development  process: 
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•  Coordinated  (exchanging  files,  interfacing  software)  -  Independent  lETM  and  training 
product  development  with  planned  and  coordinated  exchange  of  lETM  files,  software,  etc. 
for  interface  with  automated  curriculum  development  programs. 

•  Concurrent  (developing  some  shared  data,  sharing/interfacing  software)  -  Simultaneous, 
planned,  and  coordinated  development  of  lETM  and  training  support  products;  development 
and  use  of  shared  data  and  software;  initial  joint  planning  and  requirements  determination 
which  enable  data  integration  into  the  training  curriculum. 

•  Integrated  (developing  a  shared  database;  sharing  software)  -  Structured,  concurrent,  and 
shared  development  of  all  maintenance,  operations,  and  training  materials  into  a  single,  fully 
integrated  database  that  uses  multiple  tailored  view  packages  to  present  material  to  various 
users. 

•  Embedded  -  Combining  all  requirements  and  materials  into  an  integrated  database  with  a 
single  view  package  so  that  training  materials  are  indistinguishable  from  maintenance, 
operations,  and  other  materials;  enable  operations,  maintenance,  and  training  personnel  to  use 
a  single  product. 

In  its  initial  planning,  the  Program  Manager  must  decide  which  approach  will  provide  the  most 
benefit,  including  acquisition  and  support  of  both  lETM  and  training  requirements  throughout 
the  life-cycle.  As  training  will  have  a  significant  impact  on  both  acquisition  and  life-cycle  costs, 
these  decisions  may  affect  the  choice  of  lETM  that  will  most  appropriately  support  the  system 
and  military  unit. 

C.3  Logistic  Organization  Changes 

The  electronic  training  and  lETM  interface  has  organizational  implications  for  both  the 
Government  and  contractors/developers.  Traditional  logistic  organizations  are  divided  into 
product-oriented  groups  (e.g.,  provisioning,  training,  technical  manuals)  that  support  specific 
logistic  functions,  such  as  supply  support,  training  and  maintenance.  Differing  requirements, 
goals,  timing,  and  funding  have  served  to  keep  these  products  and  the  development  processes 
unique.  The  Logistics  Support  Manager  oversees  and  manages  the  assignment,  coordination, 
and  synchronization  of  logistic  product  development.  The  development  of  an  lETM  offers  a 
fresh  opportunity  to  combine  separate  logistic  functions  into  a  single  effort  that  focuses  the 
leadership  and  work  force  of  the  entire  logistic  spectrum.  This  confluence  should  also  improve 
the  quality  and  consistency  of  all  logistic  products,  while  reducing  both  initial  and  life-cycle 
resource  requirements.  For  example,  the  technician  who  repairs  and  the  instructor  who  teaches 
about  the  item  can  pool  their  knowledge  and  develop  a  single  set  of  data  that  satisfies  multiple 
requirements  and  augments  and  enhances  work  performance  and  quality  at  any  maintenance 
level.  The  writer  could  be  either  a  subject  matter  expert  (SME)  or  a  third  party  skilled  in 
preparing  technical  data.  This  would  ensure  that  data  is  sufficiently  granular,  or  properly 
subdivided,  to  satisfy  multiple  requirements  and  enhance  work  performance  at  the  organizational 
or  intermediate  level. 
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C.3.1  Concurrent  Development  of  Technical  Logistic  Information  and  Training 

Under  the  accelerated  and  integrated  acquisition  processes  for  new  ships,  aircraft,  and  weapon 
systems,  training  (e.g.,  course  curriculum)  and  technical  manual  data  needed  to  teach  a  course 
may  be  jointly  and  concurrently  developed.  Occasionally,  the  training  schedule  may  even 
require  that  training  begins  before  the  system  or  its  technical  manual  is  complete.  Traditionally, 
the  basic  outline  of  the  technical  manual  is  developed  from  an  approved  book  plan  that  contains 
all  paragraph  elements,  tables,  and  figures  needed  to  support  a  basic  curriculum  plan.  Because  a 
Class  rV/V  technical  manual  will  at  least  have  all  of  the  required  data,  but  will  not  have  the 
traditional  publishing  organization,  the  equivalent  of  a  book  plan  must  be  developed  to  provide 
the  definitions  and  relationships  that  satisfy  the  need  for  understandable  and  mutually  agreeable 
“hooks.”  This  navigation  tool  is  then  populated  with  cross-references  between  traditional 
organizational  elements  and  object  identification  (ID)  for  each  element.  The  cross-reference  IDs 
are  stored  and  managed  in  a  database  and  provide  the  links  in  the  final  product.  As  more 
detailed  information  is  developed  by  TM  authors,  the  IDs  can  be  expanded  under  this  structure. 
These  new  IDs  are  made  available  to  curriculum  authors  who  use  them  to  improve  the  accuracy 
of  the  curriculum  references.  It  is  easier  to  integrate  a  static-  or  completed-data  set  with  a 
developing-data  set.  But  in  the  case  of  parallel  development,  integration  is  part  of  the  overall 
process  during  creation  of  both  data  sets. 

C.3.2  Interface  Versus  Integration  of  Training  and  lETMs 

Selection  and  design  of  the  database  is  among  the  more  sophisticated  and  technical  decisions  that 
need  to  be  made.  There  are  essentially  two  choices.  The  first  is  to  divide  and  manage  the  TM 
data  as  objects  that  are  some  variant  of  their  original  form  (i.e.,  raster-scanned  page,  tagged 
paragraph,  warning,  title,  etc).  For  text  files  already  in  digital  form  (Class  H/III),  data  are 
generally  tagged  in  accordance  with  MIL-PRF-28001  with  little  or  no  significant  re-authoring. 
The  file  may  remain  in  a  linear  format,  particularly  where  hard-copy  versions  of  the  TM  are  also 
required. 

This  orientation  toward  hard-copy  product  formats  is  well  suited  to  existing  training  processes, 
where  traditional  linking  ties  data  (e.g.,  paragraphs,  tables,  figures,  videos)  to  specific  learning 
objectives.  The  data  extracted  from  the  lETM,  however,  must  often  be  processed  to  glean  only  a 
specific  portion  needed  to  meet  a  learning  objective.  As  an  example,  an  lETM  paragraph 
generally  contains  extraneous  or  excessive  data  that  can  obscure  the  point  of  the  learning 
objective  or  confuse  the  student.  This  excess  data  must  be  edited  out.  Legacy  data  conversions 
that  attempt  to  fully  accommodate  these  training  requirements  may  find  that  additional  data 
handling,  authoring  and  processing  may  add  sufficiently  to  conversion  costs  to  change  the  initial 
decisions  on  the  selection  of  lETM  or  conversion  type. 

The  other  choice  is  to  build  the  data  as  an  object  (Class  IV/V)  database,  where  information  is 
broken  down  into  small  units  (steps)  that  are  connected  by  the  inherent  logical  hierarchical 
structure  of  the  database  (as  discussed  in  MIL-PRF-87269).  T5q)ically,  this  process  will  evolve 
from  a  new  acquisition  or  major  modernization  where  the  documentation  is  already  being 
substantially  redone.  A  significant  advantage  is  that  an  integrated  team  of  training  and  TM 
authors  can  ensure  that  these  steps  are  at  the  smallest  logical  unit  that  accommodates  both  TM 
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and  training  team  members  and  are  phrased  with  language  that  can  be  used  by  both  with  no 
additional  processing. 

Curriculum  connections  are  made  at  points  in  the  hierarchical  structure  that  provide  access  to 
sets  of  data  that  may  include  graphics,  animations  and  audio.  For  the  maintainer,  these  data  sets 
can  vary  based  on  actual  conditions  found  at  each  decision  point.  That  is,  the  lETM  can  propose 
alternate  courses  of  action  based  on  input  from  the  technician,  equipment  historical  files, 
diagnostic  data,  maintenance  schedules  and  a  variety  of  other  factors.  Because  of  specific 
training  objectives,  the  trainee’s  use  is  more  constrained.  This  mandates  a  more  active  training 
role  in  concurrent  development  of  electronic  training  and  lETM  requirements  and  products  to 
maximize  the  benefits.  Significant  initial  planning  and  coordination  is  needed,  but  huge  benefits 
can  accrue  in  the  elimination  of  initial  redundant  efforts  (e.g.,  authoring,  reviews,  formatting, 
storage)  and  data.  The  reduction  in  life-cycle  costs  is  also  significant,  but  difficult  to  fully 
measure  at  this  time  due  to  the  lack  of  much  practical  experience  with  a  sufficient  number  of 
mature,  fielded  systems. 

Early  program  decisions  on  the  most  beneficial  approach  enable  coordinated  planning  for 
support  of  both  sets  of  requirements  throughout  the  life  cycle.  As  training  will  have  a  significant 
impact  on  both  acquisition  and  life-cycle  costs,  these  decisions  may  also  affect  the  choice  of  the 
most  appropriate  lETM. 

C.3.3  Life-cycle  Configuration  Management  and  Update  Considerations 

Budgeting,  funding  sources  and  priorities,  update  cycles,  and  distribution  vary  significantly 
between  the  hardware  and  required  logistic  products.  On  one  hand,  an  interfaced  or  integrated 
logistic  system  can  substantially  reduce  life-cycle  costs  and  improve  user  performance.  On  the 
other  hand,  failure  of  any  portion  of  the  system  to  effect  changes  on  a  timely  or  synchronized 
basis  can  rapidly  lead  to  disconnects  in  the  existing  manual  system.  In  comparing  electronic 
database  with  manual  counterparts,  the  difference  is  that  manual  systems  generally  allow  users  to 
“make  do”  with  available  data;  the  computer  may  simply  provide  a  “file  not  found”  message  that 
will  severely  frustrate  users  and  may  actually  negatively  impact  readiness.  Proper  planning  and 
process  modification  are  needed  to  ensure  that  a  single  engineering  update  is  sufficient  to  satisfy 
all  logistic  needs  and  ensure  appropriate  modifications  are  made  to  the  logistic  infrastructure. 

Traditionally,  training  lags  other  equipment  and  logistic  changes  by  weeks  or  months. 
Synchronization  of  the  electronic  training  and  lETM  products  demands  that  changes  occur 
simultaneously.  There  is  currently  no  formal  mechanism  or  to  ensure  this  happens.  Failure  to  do 
so  may  either  cause  electronic  products  to  simply  stop  working  (e.g.,  the  training  system  is 
unable  to  find  expected  data  and  “crashes”)  or  all  joint  users  will  be  forced  to  use  the  last 
common  revision,  even  though  it  does  not  reflect  current  installations.  Where  the  lETM  is 
embedded  within  the  operating  system  of  the  actual  hardware  system,  this  problem  can  become 
even  more  complex  and  life-cycle  planning  must  account  for  it  in  overall  system  deployment  and 
operational  plans. 
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C.3.4  Field  Interface  and  Responsibilities 

Reduction  of  costs  for  life-cycle  support  is  a  key  objective  for  both  automated  training  and  lETM 
development.  Both  consider  automated  processes  for  reducing  development  and  update  costs 
and  for  improving  the  delivery  of  the  data  to  the  user.  For  training,  fewer  classroom  hours  may 
be  a  key  measure  of  success.  It  may  reduce  the  number  of  instructors  and  students  in  the  training 
pipeline.  The  lETM  similarly  enables  personnel  with  less  skill  or  little  training  to  perform 
functions  at  an  acceptable  level  of  performance.  In  both  cases,  the  net  result  is  that  training  costs 
can  be  reduced  and  maintainers  who  are  able  to  perform  increasingly  sophisticated  and 
demanding  work,  are  available  sooner. 

C.3.5  Mutual  Functionality 

Adding  training  developers,  instructors,  students,  and  other  related  users  into  the  lETM 
requirements  increases  the  complexity  but  does  not  change  the  decision-making  process  for 
functionality  determination.  Three  elements  are  involved;  function,  functionality,  and  feature. 
Function  is  the  customer  task  that  must  be  satisfied  (e.g.,  manage  and  update  drawings). 
Functionality  is  the  capability  to  perform  that  function.  For  example,  the  function  “update 
drawings”  may  be  satisfied  by  “edit  3D  CAD,”  “edit  2D  CAD,”  “edit  with  vector  over  raster,” 
“edit  raster”  or  “input  new  drawing.”  The  products  derived  from  each  are  clearly  different. 
There  is  also  a  substantial  difference  in  the  infrastructure  investment,  training  and  life-cycle  costs 
required  for  each.  Thus,  while  giving  the  user  the  ability  to  “walk  around”  a  3D  version  of  the 
system  is  desirable,  the  benefits  may  not  justify  the  life-cycle  costs  of  maintaining  a  3D  model  of 
each  system. 

The  choice  of  functionality,  therefore,  depends  upon  potential  cost,  priority,  expected  uses  of  the 
resulting  product,  projected  benefit  and  other  related  factors.  Once  selected,  various  software 
packages  arc  examined  for  features  (i.e.,  how  the  functionality  is  provided).  For  example,  all 
major  word  processing  programs  can  “create  tables.”  How  they  are  created,  edited,  modified, 
and  tailored  are  features.  If  the  user  has  few  or  relatively  simple  tables,  this  may  be  an 
interesting,  but  inconsequential  feature.  If  much  of  the  prospective  data  is  tabular,  this  critical 
feature  may  decide  which  software  is  selected. 

Training  may  increase  the  functionality  requirements  and  probably  will  change  the  priority  and 
importance  of  specific  functionality.  Specific  features  may  be  critical  to  training,  but  not  to 
developers  or  maintainers  and  vice  versa,  thus  complicating  software  selection.  Most  programs 
also  provide  a  range  of  functionality  so  decisions  may  involve  some  duplication  or  sub- 
optimization  of  functionalities  to  obtain  the  most  cost  effective  or  productive  mix.  The  addition 
of  training  requirements  and  functionality  may  also  impact  the  selection  of  the  database 
management  system  and  associated  presentation  software  and  hardware.  Thus,  training  input 
must  be  an  integral  part  of  this  decision-making  process  in  order  to  ensure  an  optimal  mix  of 
software  that  works  together  and  provides  at  least  adequate  functionality  for  all  potential  users. 

C.3.6  Migration 

Using  standard  formats,  selecting  mainstream  software  and  hardware,  documenting  processes, 
purifying  and  managing  data  are  all  critical  to  having  a  system  that  is  able  to  continuously  satisfy 
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the  functional  requirements  of  users.  It  is  essential  to  migrate  source  data  to  a  common  format 
prior  to  developing  a  cohesive  training/IETM  program. 

Planning  for  orderly  progress  is  challenging  when  migration  is  unilateral  (TMs),  but  it  becomes 
significantly  more  complex  when  migration  is  multilateral  (e.g.,  TMs,  training,  supply  support). 
This  is  particularly  tme  where  programs  have  followed  the  “rules”  and  are  using  C/NDI 
resources.  A  prime  benefit  of  C/NDI  products  is  that  they  are  constantly  upgraded  and  improved 
at  modest  or  no  cost  to  the  Government.  However,  C/NDI  sometimes  require  application 
tailoring  or  selection  of  application  options.  Further,  when  multiple  C/NDI  packages  are  used, 
the  specific  interface  and  integration  tailoring  is  left  to  the  using  activity.  Thus,  any  C/NDI 
upgrade  may  upset  the  balance  between  packages,  leading  to  significant  programming,  re¬ 
tailoring  or  worse.  The  problem  can  be  significant  when  the  original  developer  is  still  engaged, 
but  can  be  severe  when  the  system  has  been  turned  over  to  a  Government  maintenance  activity 
that  is  not  familiar  with  or  prepared  to  update  the  integration  software. 

With  multiple  migration  paths  to  consider,  a  key  part  of  strategic  planning  is  to  determine  where 
interfaces  and  integration  occur  and  how  they  are  impacted.  For  example,  if  multiple 
presentation  systems  feed  off  of  the  same  database,  each  can  be  independently  upgraded  without 
direct  impact  so  long  as  the  interface  with  the  database  is  constant.  Modifying  the  database, 
however,  may  impact  all  application  programs.  These  problems  cannot  be  solved  by  strategic 
planning,  but  can  be  addressed  with  management  attention  focused  on  key  decisions  to  mitigate 
impact. 

C.4  Interactive  Courseware  (ICW) 

Another  viable  training  program  to  consider  integrating  with  an  lETM  ICW.  ICW  differs  from 
other  training  programs  in  that  it  is  self-paced.  The  following  paragraphs  discuss  the 
fundamentals  of  a  combined  lETM-ICW  program. 

C.4.1  ICW  Definition 

MIL-HDBK-284-3  defines  interactive  courseware  as  denoting  either  of  the  following; 

•  “A  computer  program-controlled  instruction  that  relies  on  trainee  input  to  determine  the 
order  and  pace  of  instructional  delivery.  The  trainee  advances  through  the  sequence  of 
instructional  events  by  making  decisions  and  selections.  The  instruction  branches  according 
to  the  trainee's  responses.” 

•  “A  term  referring  to  any  type  of  computerized  instruction  characterized  by  the  ability  of  the 
trainee  to  respond  through  an  input  device.  ICW  may  be  an  integral  part  of  computer-based 
instruction  (CBI),  computer  aided  instruction  (CAI),  and  computer-based  training  (CBT)." 

ICW  specifications  and  guides  support  the  development  of  highly  realistic,  efficient  training  with 
the  end-user  considered  the  primary  focus  of  courseware  design  and  information  presentation. 
Within  financial  and  logistic  constraints  and  without  compromising  training  effectiveness,  ICW 
is  expected  to  provide: 
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•  A  user-friendly  trainee  interface  and  lesson  structure 

•  Accurate,  up-to-date  technical  information  and  procedures 

•  Instruction,  segmented  to  provide  meaningful  training 

•  Extensive  use  of  help  routines  and  remediation 

•  Individualized  tailored  instruction 

•  Confirmation  of  learning  by  immediate  and/or  delayed  lesson-  and  content-specific 
feedback 

C.4.2  Introduction  and  Background 

ICW  is  based  on  a  systems  approach  and  a  well  established  Instructional  Systems  Development 
(ISD)  model  with  six  basic  phases:  analysis,  design,  development,  implementation,  evaluation 
and  revision.  ICW  has  evolved  from  different  forms  of  instruction  delivered  by  way  of 
computer.  In  an  optimally  designed  course,  the  learner’s  decisions  and  inputs  determine  the 
level,  order,  and  pace  of  instructional  delivery,  and  forms  of  individualized  visual  or  aural 
outputs.  Interactivity  ranges  from  simple  button  pushing  to  complex  inputs,  content-specific 
feedback  and  remediation.  ICW  is  used  in  a  variety  of  educational  and  commercial  training 
environments  as  well  as  Government  and  military  training  programs.  It  may: 

•  Present  information  by  text,  graphics  and  sound 

•  Elicit  learner  responses  through  various  prompted  and  unprompted  strategies 

•  Provide  feedback,  remediation,  and  testing 

•  Provide  practice  in  simulated  tasks  and  decision-making  scenarios 
User  control  varies  from  limited  navigational  to  complete  control. 

C.4.3  ICW  Production  and  Display 

ICW  consists  of  text,  graphics,  and  computer  programming  and/or  scripting  instructions 
assembled  into  a  logical  structure  designed  to  convey  facts,  concepts,  procedures,  and  to  provide 
instruction  and  practice  in  problem  solving. 

C.4.3.1  ICW  Production 

Assembling  the  various  elements  of  ICW  is  commonly  called  authoring.  Authoring  software 
packages  are  available  for  a  variety  of  computer  platforms  including  Microsoft  Windows'!''^  and 
Macintosh^'^-based  systems.  Most  authoring  programs  provide  the  capability  to  access  or  call-in 
external  programs,  while  the  instructional  program  is  running.  ICW  may  be  produced  on  various 
configurations  of  computer  hardware.  The  current  trend  is  to  produce  ICW  on  multimedia  PCs 
or  Macintoshes.  Video  and  sound  cards,  SVGA  monitors,  and  built-in  CD  players  are  required. 
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The  PCs  may  be  stand-alone  or  part  of  a  computer  network.  A  general  overview  of  the 
production  process  for  the  ISD  system  and  ICW  subsystem  is  shown  in  Figure  C-1 . 

ISD/ICW  Production  Process 
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Figure  C-1.  ISD  System  and  ICW  Subsystem 


C.4.3.2  Display  Software/Hardware  and  User  Needs 

A  runtime  version  of  the  authoring  software  is  normally  used  as  the  presentation  software. 
Ideally,  an  ICW  developer  should  determine  in  advance  the  computer  specifications  of  the 
intended  user’s  computer.  Material  that  displays  just  fine  on  a  powerful  developer’s  computer 
may  not  display  at  all  on  a  user’s  less  capable  computer.  Due  to  their  small  size,  portability,  and 
increasing  capacity  and  capabilities,  laptop  computers  are  increasingly  popular  as  ICW  delivery 
hardware.  As  deployed  military  units  have  critical  space  and  weight  limitations,  having  all 
training  combined  with  the  technical  information  (i.e.,  lETM)  on  a  compact  medium  is 
advantageous. 

C.4.4  lETM  -  ICW  Interface 

There  are  many  obvious  mutual  benefits  to  interfacing  ICW  with  lETMs.  From  an  lETM 
perspective,  the  user  can  access  content-specific  instructional  materials  to  refresh  or  augment 
technical  concepts  or  enhance  performance  of  procedures.  From  an  ICW  perspective,  the 
necessary  learning  elements  (e.g.,  menus,  objectives,  and  embedded  questions)  are  resident  in  the 
ICW.  Moreover,  during  an  ICW  lesson,  the  instructor  will  also  have  on-line  access  to  extensive 
depth  and  scope  of  referenced  interactive  technical  information  from  an  lETM  database.  This 
will  substantially  expand  the  instructor’s  ability  to  provide  realistic,  real-time  responses  to 
student  requirements,  queries,  etc.  There  is,  however,  a  key  issue.  Training  and  its  associated 
funding  frequently  lag  introduction  and  changes  to  the  weapon  systems  by  as  much  as  two  years. 
Therefore,  training  (i.e.,  the  ICW)  may  be  "generic"  in  nature  and  may  not  be  complete  or 
technically  accurate.  Conversely,  an  lETM  requires  timely  upgrades,  changes,  and  modifications 
—  commensurate  with  the  system  it  supports.  The  issue  of  synchronizing  updates  and  funding 
will  be  addressed  in  more  detail  later  in  this  chapter. 
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C.4.4.1  Comparison  of  Categories  of  ICW  with  Classes  (I  -  V)  lETM 


lETMs  and  ICW  can  be  classified  and  compared  in  terms  of  their  interactivity  and  branching 
capabilities.  The  following  discussion  uses  these  designations  as  a  preliminary  point  of 
comparison.  The  lETM  classifications  have  been  defined  previously  and  are  summarized  as: 

•  Class  I  -  Electronically  Indexed  Page  Images 

•  Class  n  -  Electronic  Scrolling  Documents 

•  Class  ni  -  Linear  Structured  lETMs 

•  Class  rv  -  Hierarchically  Structured  BETMs 

•  Class  V  -  Integrated  Database  lETMs 

MIL-HDBK-284-3  has  categorized  ICW  by  three  general  levels  of  interactivity  as  shown  in 
Table  C-1. 

Category  3  ICW  presentation  of  data  is  similar  to  the  functionality  of  Class  HI,  IV,  and  V 
lETMs. 

C.4.4.2  ICW  and  lETM  Commonalty  and  Differences 

While  there  will  be  differences  in  the  specific  presentation  of  the  material,  it  is  clear  that  there 
can  and  should  be  an  exact  match  between  data  presented  in  ICW  and  in  a  corresponding  lETM. 
The  same  discrete  set  of  technical  data  (e.g.,  technical  manual  data,  drawings,  animations,  expert 
systems  modules,  videos,  text  items,  training  review  questions,  and  audio  clips)  should  appear  in 
both  view  packages.  However,  it  is  also  clear  that  the  needs  of  and  results  required  by  the 
maintenance  technician  may  be  quite  different  from  those  of  the  student.  Consequently,  while 
the  whole  set  of  data  should  be  the  same,  each  user  will  be  working  from  a  tailored  subset  of  that 
data.' There  are  other  important  differences  in  the  underlying  foundations  and  design  of  lETMs 
and  ICW  that  determine  how  the  lETMs  or  ICW  lessons  are  programmed  and  the  type  of 
navigation  and  access  capabilities  that  are  needed  for  the  two  information  presentation  systems. 
It  is  therefore  critical  that  technical  information  be  developed  in  a  concurrent  engineering 
environment  to  ensure  that  a  single  set  of  data  can  fulfill  all  of  its  intended  roles. 
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Table  C-1.  ICW  Categories  of  Interactivity 


Presentation 

Description 

Category  1  - 
Baseline 

A  knowledge-based  or  familiarization  lesson,  in  linear  format,  used  for 
introducing  an  idea  or  concept  with  minimum  trainee  interactivity,  (i.e.,  the 
trainee  has  little  control  of  what  is  seen).  There  are  two  types: 

•  Video  and  minor  text  presentation 

•  Graphics  and  minor  text  presentation 

Category  2  - 

Medium 

Simulation 

A  lesson  that  involves  the  recall  of  more  information  and  a  moderate  degree  of 
simulation  and  that  allows  the  trainee  increased  control  over  the  presentation. 
This  presentation: 

•  Provides  combined  information  and  skills  lessons 

•  Requires  a  moderate  degree  of  programming 

•  Provides  trainee  interactivity  with  various  input/output  devices 

•  Provides  computer-managed  instruction  to  track  and  analyze  student 
performance 

•  Normally  combines  video  and  graphics  presentations 

Category  3  - 
High 

Simulation 

This  lesson  uses  the  full  capabilities  of  ICW  with  every  subtask  analyzed  and 
presented  for  full,  on-screen  interaction,  similar  to  that  used  in  aircraft  simulator 
technology.  The  trainee  determines  areas  where  further  training  is  desired. 

This  presentation  provides: 

•  Procedural  tasks  and  skills 

•  A  high  level  of  student  interactivity 

•  Extensive  branching  capability 

•  Maximum  remediation  opportunity 

•  Real-time  event  simulation  with  minor  equipment  limitations 

•  Capability  to  interface  with  other  output  devices 

•  Exhaustive  CMI  capability 
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C.4.5  lETM  -  ICW  Interface  Scenarios 


Two  major  scenarios  for  interfacing  lETMs  with  ICW  and  the  procedural  similarities  and 
differences  in  various  acquisition  and/or  production  conditions  are  discussed:  concurrent 
development  and  developing  ICW  using  an  existing  lETM. 

C.4.5.1  Concurrent  lETM  and  ICW  Development 

Concurrent  development  is  the  optimal  method;  use  it  extensively  in  the  future  both  for  new 
manuals  and  for  major  conversions  (e.g.,  to  Class  IV)  where  significant  re-authoring  is  required. 
If  a  fully  developed  lETM  does  not  exist,  every  effort  should  be  made  to  develop  the  ICW  and 
lETM  concurrently.  The  general  processes  can  be  modified  and  adapted  to  mutually  support  the 
instructional  systems  development  associated  with  ICW  and  lETMs.  Learning  and  performance 
objectives  for  ICW  strongly  impact  the  complexity  of  its  development.  Using  specified  learning 
and  performance  objectives  and  the  technical  content  within  the  lETM,  the  ICW  design  team 
will  have  complete  and  accurate  data  to  develop  courseware  focused  on  the  user.  Factual 
information  presented  with  simple  graphics  is  easy  for  the  user  to  grasp  and  requires  less  time  to 
design,  develop,  program,  maintain,  and  update  than  complex  troubleshooting  lessons  employing 
3-dimensional  animations.  The  same  SMEs  should  be  used  for  lETM  and  ICW  development  on  a 
particular  topic. 

C.4.5.2  Development  of  ICW  Using  an  Existing  lETM 

Under  the  most  prevalent  type  of  scenario,  ICW  will  typically  be  developed  using  an  existing 
lETM.  Figure  C-2  describes  the  five  major  task  associated  with  this  process. 


Figure  C-2.  Creating  ICW  Using  an  Existing  lETM 
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C.4.6  ICW  Specifications 
C.4.6.1  Requirements  Definition 

MIL-HDBK-284-1  Appendices  A  and  B  provide  detailed  guidance  for  requirements  pertaining 
to  ICW  Front-End  Analysis  (FEA),  and  ICW  design,  development,  and  implementation. 

C.4.6.2  lETM  -  ICW  Interface  Specifications  Development 

Since  lETM-ICW  interface  specifications  are  not  currently  available,  ICW  specifications 
(developed  according  to  MIL-HDBK-284-1)  may  be  merged  with  an  lETM  specification 
developed  using  considerations  provided  elsewhere  in  this  document. 

C.4.6.3  Government  Specifications  -  ICW  Standards 

MIL-HDBK-29612  provides  tailorable  requirements  and  task  descriptions  for  acquisition  of 
military  training  programs.  Tasks  described  in  this  standard  should  be  selectively  applied  to 
DoD  contract  acquisition  and  Government  development  of  requiring  military  programs.  Specific 
task  description  number(s)  and  appropriate  paragraphs,  as  well  as  applicable  task  inputs  and  task 
outputs,  should  be  included  in  the  SOW/SOO  of  the  Request  for  Proposal  and  in  the  contract. 
The  Appendices  of  MIL-HDBK-284-1  contain  guidance  on  the  acquisition  and  support  of  ICW. 
The  requirements  are  applicable  MIL-HDBK-29612  task  descriptions  rather  than 
material/weapon  system/equipment  training  program  requirements.  The  task  descriptions  in 
MIL-HDBK-29612  are  presented  in  recommended  SOW/contract  performance  sequences. 

C.5  lETM  Interface  Decisions 

The  program  decision  to  use  an  lETM  and  interface  it  with  training  involves  a  commitment  of 
resources  to  accomplish  one  or  more  objectives  to  reduce  costs  and  improve  operational 
availability,  worker  productivity,  and  quality.  Whether  acquiring  new  data  or  converting 
existing  data  for  use  in  an  lETM,  the  program  has  three  key  decisions  to  make: 

•  Functionality  -  The  capabilities  and  features  that  are  desired 

•  Standards  -  Which  Government,  commercial,  performance  (or  other)  standards  will  be 
required 

•  Data  structure  -  How  the  data  will  be  created  or  assembled,  managed,  and  related  to  itself, 
associated  data,  and  its  environment  and  parent  equipment 

Each  decision  is  an  enabler,  facilitator  or  constraint  for  other  decisions.  For  simplicity,  decisions 
on  data  structure,  standards,  and  functionality  will  be  collectively  referred  to  as  “functionality” 
unless  otherwise  noted.  Clearly,  the  functionality  selected  has  critical  impact  on: 

•  Cost  of  and  time  needed  for  conversion 

•  Users’  ability  to  gather  and  use  data 
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•  Costs  and  ability  to  maintain  and  update  the  data 

•  Ability  to  interface,  interact,  and  share  data  with  other  logistic  processes  and  data  files 

•  Ability,  cost,  and  effort  to  migrate  in  the  future  to  newer  technology 


C.6  Training  Impact  on  CONOPS  Development 

The  decisions  on  whether  to  produce  an  lETM,  what  kind  of  lETM,  and  how  the  lETM  will 
connect  with  other  requirements  (e.g.,  training)  to  improve  logistic  support,  are  lengthy, 
complex,  and  interrelated.  Conveying  the  breadth  of  background,  knowledge,  and  understanding 
needed  to  derive  the  product  desired  is  made  more  difficult  by  adding  training  factors  and 
considerations.  This  further  supports  the  concept  of  documenting  factors  and  decisions  and 
establishing  the  conditions  within  and  under  which  the  lETM  and  training  products  will  function. 
Preparing  the  CONOPS  and  expanding  it  to  include  these  additional  considerations  is  still  the 
most  effective  approach  to  clarify  issues  and  establish  parameters  to  help  a  manager  select 
optimal  lETM  functionality  levels  consistent  with  program  lETM  and  training  requirements. 
TTie  Program  Manager  can  then  develop  performance  statements,  mapped  to  conditions  in  the 
CONOPS,  to  use  in  the  TMCR  and  any  other  required  documents  that  deals  with  the  interface  of 
lETMs  and  training  products.  Additionally,  as  training  and  lETMs  become  more  intertwined, 
the  existence  of  an  organized  and  structured  way  of  monitoring,  acknowledging,  and  addressing 
the  total  impact  of  change  can  provide  insight  and  understanding  and  obviate  the  need  for  hasty 
or  ad  hoc  changes.  By  highlighting  and  monitoring  factors  that  are  critical  to  lETM  and  training 
success,  decision  processes  can  be  periodically  or  specifically  revisited  and  parameters  adjusted, 
if  necessary,  to  ensure  that  change  is  accommodated  and  continued  success  is  assured. 

The  lETM  Functionality  Determination  Model  (Figure  5-2)  identifies  and  projects  the  hardware 
or  weapon  system  characteristics  (whether  already  in  the  field  or  being  prepared  for  acquisition 
or  introduction)  that  define  the  supporting  lETM  functionality  requirements  and  uses  them  to 
develop  the  lETM  CONOPS.  Integration  of  the  training  requirements  into  this  decision  set 
during  the  initial  lETM  requirements  development  is  desirable  as  it  will  provide  the  optimal 
results.  However,  even  if  lETM  determinations  have  already  been  made  and  are  underway,  use 
of  the  model  to  include  and  assess  required  training  functionality  provides  a  process  for  ensuring 
that  all  factors  have  been  considered  within  the  context  of  the  original  decisions.  Where  the 
training  input  suggests  changes  are  required,  the  Program  and  Logistics  Managers  will  be  able  to 
properly  and  completely  assess  the  impact  of  proposed  actions.  This  review  may  also  prompt  a 
review  of  the  initial  decisions  and  factors  to  determine  whether  other  changes  are  required.  In 
each  case,  managers  will  be  acting  on  a  full  set  of  facts  that  provide  a  solid  base  and  context  for 
decision-making.  Similarly,  the  results  of  these  deliberations  will  be  documented  in  revisions  to 
the  CONOPS. 
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APPENDIX  D 

AIR  FORCE  lETM  INFORMATION 


D.l  Air  Force  Strategy 

The  Air  Force’s  digital  data  strategy  seeks  to  achieve  three  primary  objectives:  first,  to  produce 
a  digital  data  management  approach  that  provides  the  Air  Force  with  JCALS  and  JEDMICS- 
compatible  digital  data;  second,  to  facilitate  user  access  to  digitized  technical  data;  and  third,  to 
exploit  technology  and  significantly  reduce  the  costs  associated  with  hard-copy  Technical  Order 
(TO)  and  engineering  data  management  processes. 

In  April  1995,  the  AF  PDSM  (Product  Data  Systems  Modernization)  Program  Office  produced 
the  Air  Force  Digital  Data  Strategy  and  its  accompanying  Technical  Order  Conversion 
Implementation  Plan.  The  Air  Force  digital  data  strategy  will  convert  approximately  16  million 
TO  pages  from  paper  to  digital  format  for  input  to  JCALS.  Through  functional  and  economic 
analysis,  the  Air  Force  has  chosen  to  convert  the  legacy  TOs  to  Indexed  Adobe®  Portable 
Document  Format  (IPDF).  This  conversion  format  will  provide  maximum  data  interchange 
utility  to  data  users  and  be  compatible  with  JCALS.  Because  they  include  indexing  and 
hyperlinks,  these  documents  are  classified  by  the  Air  Force  as  Class  II  lETMs.  Table  D-1  lists 
representative  production  figures  for  the  TO  conversion  effort. 

The  strategy  also  initiated  an  update  methodology  that  could  be  implemented  throughout  the  Air 
Force  to  provide  users  with  the  capability  to  sustain  page-based  digital  TOs.  It  should  be  noted 
that  for  the  foreseeable  future,  TO  users  will  be  using  both  paper  and  digital  products  depending 
upon  their  operating  environment  and  media  requirements.  Thus,  the  IPDF  sustainment  approach 
addresses  both  paper  and  digital  update  strategies  as  it  promotes  a  migration  to  a  "less-paper- 
intensive"  environment.  Because  of  its  substantially  higher  costs.  Class  IV  lETM  functionality  is 
being  acquired  for  only  a  few  select  programs  until  the  concept  is  proven  and  sustainment  and 
delivery  infrastructure  constraints  are  better  understood  and/or  resolved. 

The  AF  Digital  Data  Strategy  requires  that  new  TOs  be  developed  digitally  in  SGML  using  Air 
Force  content-specific  Document  Type  Definitions  (DTDs).  These  DTDs  are  appended  to  the 
Technical  Manual  Specifications  and  Standards  (TMSS).  The  SGML  TOs  should  include 
graphics  that  are  formatted  according  to  the  Computer  Graphics  Metafile  (CGM)  language; 
however,  they  can  also  contain  Initial  Graphics  Exchange  Specification  (IGES)  or  raster 
graphics. 

Prior  to  JCALS  deployment,  contractors  should  deliver  IPDF  files  generated  from  SGML  TO 
source  data  for  organically  maintained  TOs.  IPDF  files  are  platform  independent  digital  files 
that  are  suitable  for  viewing,  document  navigation,  and  print-on-demand.  Delivered  IPDF  files 
may  be  stored  and  sustained  on  the  Digital  Legacy  Data  Storage  System  (DLDSS)  until  JCALS 
is  fielded  at  the  users’  location.  DLDSS  is  an  interim  storage  capability  for  IPDF  TOs  provided 
to  each  Air  Logistics  Center  (ALC).  After  JCALS  deployment,  contractors  should  deliver 
SGML  TO  files  for  loading  onto  the  JCALS  system  for  organically  maintained  TOs.  In  addition, 
if  the  contractor  obtained  approval  from  the  PDSM  Office  to  prepare  and/or  use  DTDs  that  were 
different  from  AF  DTDs,  these  DTDs  will  also  be  delivered  to  the  Government. 
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Table  D-1.  Production  Status  of  Air  Force  TOs  (July  -  November,  1998) 


D-2 


D.2  Air  Force  Conversion  Efforts 


The  legacy  TO  conversion  effort  includes  TO  pre-conversion,  conversion,  and  post-conversion 
processes.  The  pre-conversion  process  includes  requisitioning  legacy  paper  TOs;  verifying  them 
against  the  system  List  of  Applicable  Publications  (LOAP);  making  complete  TO  books,  which 
include  changes  and  supplements;  ensuring  that  individual  pages  can  be  scanned;  and  shipping 
the  complete  TO  to  the  converting  organization.  When  TOs  are  incomplete  (missing  pages, 
missing  changes,  blurred  or  blank  pages,  etc.)  or  contain  supplements,  the  Technical  Content 
Manager  (TCM)  is  notified  of  the  corrective  action  required;  either  to  replace  pages  or  to 
incorporate  supplements  into  changes. 

The  conversion  process  includes:  converting  the  paper  TO  to  an  IPDF  file;  linking  the  TO’s 
table  of  contents,  lists  of  tables,  figures  and  illustrations,  and  alphabetical  index  with  the  TO’s 
text;  writing  it  to  digital  media;  ensuring  that  it  is  indexed  according  to  the  TO  Contract 
Requirements  (TOCR)  document;  and  then  sending  the  digital  TO  along  with  its  paper  version  to 
the  Technical  Order  Conversion  Operation  (TOCO)  for  post-conversion.  The  latest  TOCR 
document  can  be  accessed  on  the  WWW  at  http://www.pdsm.wpafb.af.mil/tocr.html. 

The  post-conversion  process  includes:  ensuring  the  IPDF  TO  has  not  lost  any  technical  content 
during  the  conversion  process;  meeting  the  requirements  in  the  TOCR  document;  maintaining 
configuration  control  of  the  TO  until  delivery;  and  shipping  the  IPDF  TOs  on  4mm  Digital 
Audio  Tape  (DAT)  or  CD-Recordable  (CD-R)  to  the  TO  Manager  at  the  managing  ALC  for 
approval  and  loading  into  the  DLDSS.  JCALS  will  be  used  for  digital  TO  sustainment  when  it  is 
fielded. 

The  Single  Manager  (SM)  should  work  with  the  TOCO  facility  to  convert  legacy  TOs.  It  is  AF 
policy  to  procure  digital  TOs  where  available  in  complete  form  rather  than  undertaking 
conversion  of  paper  TOs.  To  that  end,  SMs  should  strive  to  acquire  digital  TO  files  from  their 
contractors  if  the  TOs  are  in  complete  book  form.  These  TOs  should  be  acquired  and  delivered  in 
Postscript  format,  PDF,  or  IPDF  that  is  indexed  according  to  the  requirements  in  the  TOCR  and 
based  upon  the  contractor’s  capability  to  deliver.  TOs  delivered  by  contractors  in  Postscript, 
PDF,  or  IPDF  should  be  delivered  to  the  TOCO  facility  for  conversion  or  linking  as  required, 
and  Quality  Assurance  (QA).  For  the  TOCO  to  avoid  converting  TO  books  already  in  digital 
form,  SMs  should  contact  the  TOCO  to  identify  digital  TO  books  being  procured  from  their 
contractors. 

To  sustain  digital  TOs,  the  SM  should  eliminate  supplements.  TO  supplements  do  not  lend 
themselves  to  use  and  management  within  a  digital  environment.  While  it  is  possible  to  update 
affected  paragraphs  in  BPDF  files  by  inserting  "pointers"  (which  is  in  effect  what  a  paper 
supplement  does),  the  process  is  too  labor  intensive  for  everyday  use  in  the  field.  Therefore, 
IPDF  TOs  should  be  maintained  through  Block  Cycle  Updates  (BCUs)  and  Rapid  Action 
Changes  (RACs)  using  composed  page  changes.  The  process  for  exchanging  "pages"  in  IPDF 
documents  is  facilitated  by  the  Digital  TO  (DiTO)  Change  Incorporation  Software  (TO  00-5-1- 
101)  developed  by  the  AF  PDSM  Program  Office.  After  the  change  package  has  been  posted  or 
"merged"  into  the  baseline,  the  TO  is  linked  using  C/NDI  software  packages.  These  software 
packages  include  InfoLinker  that,  in  conjunction  with  a  "rules  file"  automatically  generates  links 
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within  a  document,  and  LinkManager,  which  manipulates  the  instance  and  appearance  of  the 
links.  The  complete  AF  change  process  is  further  detailed  in  the  SM  Guide. 

D.3  Air  Force  lETM  Display  Equipment 

Program  Managers  who  elect  to  acquire  lETMs  should  ensure  that  display  devices  and 
accompanying  software  have  the  capability  to  view  IPDF  files  so  digitized  legacy  data  can  be 
viewed  without  the  need  for  conversion  to  higher-level  lETM  format. 

The  use  of  IPDF  TOs  near  the  flightline  introduces  a  variety  of  human  factors  concerns. 
Environmental  conditions  such  as  bright  sunlight,  rain  and  dust  are  just  a  few  of  the  issues  that 
should  be  evaluated  prior  to  deployment  of  IPDF  TOs  on  the  flightline.  Great  strides  have  been 
made  in  “ruggedizing”  Portable  Maintenance  Aids  (PMAs)  for  the  harsh  military  operating 
environment.  However,  most  PMAs,  especially  those  off-the-shelf,  do  not  currently  support  the 
effective  viewing  of  IPDF  TOs. 

As  an  alternative  approach,  organizations  could  use  common-area  computers  strategically  placed 
in  aircraft  maintenance  bays  or  dispatch  vehicles,  so  crews  could  access  TOs.  The  IPDF  TOs 
could  be  stored  on  a  server  and  accessed  through  the  base  network,  or  on  a  hard  disk/CD. 
Printers  could  be  provided  if  print-on-demand  is  a  requirement. 

IPDF  TOs  may  be  used  on  an  aircraft  when  they  fulfill  unique  requirements  and  the  computers 
will  not  jeopardize  safety  of  flight.  PMAs  often  interfere  with  onboard  navigation  and  safety 
equipment.  Once  approval  is  received  for  using  these  computers,  portable  display  devices  or 
built-in  computer  systems  should  be  considered  for  in-flight  use.  Desktop  PCs  are  not  conducive 
to  aircraft  operations  because  of  the  space  limitations  and  onboard  power  systems  of  the  aircraft. 
Access  to  IPDF  TOs  onboard  the  aircraft  may  be  through  CD  or  computer  hard  drive.  Online 
access  to  TOs  from  positions  within  the  aircraft  may  be  possible  if  a  LAN  access  system  is  part 
of  the  aircraft  system. 

D.3.1  Joint  Integrated  Maintenance  Information  System  (JIMIS) 

JIMIS  is  a  product  of  the  Northrop  Grumman  Corporation  deployed  in  the  Joint  Surveillance 
Target  Attack  Radar  System  (JSTARS)  community  (Wamer-Robbins  AFB).  The  JIMIS  program 
currently  sustains  JSTARS  TOs  in  a  parallel  paper  and  Class  IV  lETM  environment.  The  source 
data,  originally  paper,  is  being  completely  re-authored  to  conform  to  a  Class  IV  database 
structure.  JIMIS  displays  CALS -compliant  technical  data  electronically  for  the  Air  Force 
technician.  Its  primary  function  is  the  rapid  retrieval  and  presentation  of  technical  data  (TD)  for 
the  maintenance  technician.  It  can  be  deployed  in  an  office  or  shop  environment  with  off-the- 
shelf  PC  workstations  or  in  a  harsh  environment  with  ruggedized  PMAs  running  X-Windows. 

The  JIMIS  sustainment  plan  calls  for  periodic  updates  of  JSTARS  data  every  75  days.  The 
contractor  supplies  the  updated  information  on  4mm  storage  tape  to  base  personnel  who  mass 
replicate  the  data  onto  small  hard  drives.  The  drives  are  disseminated  to  the  appropriate 
personnel  who  return  a  hard  drive  containing  the  old  data.  The  recycling  of  hard  drives  has 
continued  throughout  the  JIMIS  program  without  experiencing  a  single  hard  drive  failure. 
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D.4  Online  Resources 


The  best  starting  point  for  obtaining  Air  Force  TO  information  is  the  PDSM  home  page  at 
http://wpaftbl.wpafb.af.mil/.  The  page  contains  numerous  links  to  strategy  and  guidance  policy, 
TO  conversion  information,  and  other  digitization  efforts.  Of  particular  note,  download  the 
USAF  Single  Manager’s  Guide  For  Implementing  Digital  Technical  Orders  at 
http://wpaftbl.wpafb.af.mil/datamgt/singmgr.htm.  This  SM  Guide  contains  the  AF  integrated 
approach  to  implementing  digital  TOs.  The  integrated  approach  was  produced  to  support  AF 
SMs  in  meeting  the  challenge  of  acquiring  and  sustaining  page-oriented  digital  TOs.  The  Guide 
applies  to  all  TO  acquisition  and  sustainment  programs  supporting  systems  developed,  deployed, 
or  managed  by  the  Air  Force.  In  addition,  it  applies  to  newly  acquired  digital  TOs  as  well  as  to 
legacy  TOs  being  managed  either  organically  or  by  contractors.  SMs  should  use  this  Guide  to 
acquire  new  digital  TOs,  and  to  convert,  sustain,  and  distribute  legacy  TOs.  The  Guide  identifies 
SM  responsibilities,  which  will  be  required  to  implement  a  series  of  steps  and  processes  to 
prepare  their  weapon  systems  for  entry  into  an  IDE.  It  also  provides  sample  wording  to  use  in  a 
SOO/SOW  and  describes  inputs  to  various  sections  of  an  RFP. 

Air  Force  acquisition  managers  may  obtain  the  Joint  Service  CALS  Reference  Toolkit  on  CD  at 
http://wpaftbl.wpafb.af.mil/train/calstool.htm.  This  CD  contains  the  DoD  Government  Concept 
of  Operations  (GCO)  Generator  Tool;  the  CALS  specs  and  standards  in  PDF  format  along  with 
the  Adobe  Acrobat  Readers;  Joint  Service  information  on  JCALS,  JEDMICS,  CMIS,  and  more. 
AF  Technical  Manual  Contract  Requirements  (TMCR),  TM-86-01G,  1  Dec  1998  in  Word  6.0 
format,  can  be  found  at  http://wpaftbl.wpafb.af.mil/toprac/WORKING.HTM.  A  copy  of  the 
instructions  for  use  of  the  TMCR  (TO  00-5-3),  a  generic  TO  Management  Plan  and  a  Generic 
TO  Verification  Plan,  can  also  be  obtained  at  this  Web  site. 

The  Air  Force  offers  two  methods  for  obtaining  training  on  digitized  TOs.  A  CBT  course  for  TO 
Acquisition  and  Sustainment  can  be  downloaded  from  http://wpaftbl.wpafb.af.mil/toprac/ 
to2sys2.htm#TOCBT.  The  course  (Figure  D-1)  is  a  desktop  computer  Windows-based  software 
product  that  provides  in-depth  detailed  information  on  TO  acquisition  and  sustainment 
management  concepts,  policy,  and  processes.  The  CBT  course  is  divided  into  10  lesson  modules: 

•  Lesson  1 :  Air  Force  TO  System 

•  Lesson  2:  TO  Acquisition  and  Management 

•  Lesson  3:  Interface 

•  Lesson  4:  Budget  and  Cost 

•  Lesson  5:  Technical  Manual  Contract  Requirements  (TMCR) 

•  Lesson  6:  Digital  Data 

•  Lesson  7:  Technical  Manual  Specifications  and  Standards  (TMSS) 

•  Lesson  8:  Time  Compliance  TOs  (TCTOs) 
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•  Lesson  9:  Improvement  and  Update 

•  Lesson  10:  Printing  and  Distribution 

Contact  HQ  MSG/ILMP,  Ms.  Pam  Sutton  at  DSN  787-3085  or  e-mail:  suttonp@afcpo.wpafb. 
af.mil  for  more  information  on  the  course  and  its  content. 


Figure  D-1.  Sample  Screens  from  TO  CBT  Course 


D.5  Acquisition  Classroom  Instruction 

AF  acquisition  managers  can  also  attend  a  one  day  course  for  Digital  Data  Product  Acquisition. 
This  course  is  designed  for  presentation  at  customer  sites  for  audiences  of  ten  to  thirty  students. 
Customer  organizations  are  to  fund  the  TDY  cost  of  one  Air  Force  CALS  Program  Office 
representative  to  present  the  course  material.  The  course  abstract  and  outline  are  presented 
below.  The  AF  PDSM  Program  Office  (DSN  787-3085)  can  be  contacted  for  more  information 
about  this  course. 

D.5.1  Course  Abstract 

Description:  This  course  will  train  Air  Force  personnel  in  effectively  acquiring  digital  weapon 
system  product  data  within  the  current  acquisition  reform  environment.  Emphasis  is  placed  upon 
how  to  develop  an  RFP  that  will  result  in  delivery  of  digital  technical  orders  and  engineering 
data  that  are  compatible  with  JCALS  and  JEDMICS  respectively.  Particular  attention  is  paid  to 
development  of  the  digital  data  GCO,  contractual  language  development  for  digital  product  data 
acquisition,  and  other  topics  that  will  enable  Air  Force  weapon  system  SMs,  supporters,  and 
users  to  more  effectively  function  within  the  Integrated  Product  Data  Environment  (IPDE). 

Target  Audience:  Course  is  targeted  towards  acquisition  logisticians,  engineers,  and  data 
managers  at  Air  Force  product  centers.  Air  Logistics  Centers,  and  operating  locations.  In 
addition,  a  two-hour  executive  summary  briefing  is  available. 
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Learning  Objectives; 

•  To  understand  how  to  produce  an  effective  RFP  for  acquiring  digital  product  data  in  JCALS 
and  JEDMICS  compatible  format  (reflects  the  latest  Acquisition  Reform  information). 

•  To  obtain  a  working  level  knowledge  of  digital  data  types;  and  digital  data  interchange, 
format,  and  delivery/access  characteristics. 

•  To  understand  how  to  determine  digital  product  data  requirements. 

•  To  understand  DoD  and  Air  Force  information  management  policy,  strategies,  and 
infrastructure  that  frame  the  digital  product  data  acquisition  process. 

•  To  understand  techniques  that  will  facilitate  digital  data. 

Course  materials  (student  charts  that  total  97  pages)  will  be  sent  to  the  customer  site  for 
reproduction  two  weeks  in  advance  of  the  course. 

D.5.2  Digital  Data  Acquisition  Course  Outline 

Module  1: 

•  Learning  DoD’s  Digital  Data  Management  Approach 

•  Modernize  DoD’s  Infrastructure  (JCALS,  JEDMICS,  IDE) 

•  Improve  Business  Processes 

•  Acquisition  Reform  Impacts 

•  Integrate  Digital  Data  with  an  Integrated  Weapon  System  Management  (IWSM) 
Environment 

Module  2: 

•  Planning  for  Digital  Data  Acquisition 

•  Acquisition  Guidance 

•  Know  Your  Program  Characteristics 

•  Air  Force’s  Digital  Data  Implementation  Strategy 

•  Technology  Infrastructure  Assessment 
Module  3: 

•  Determining  Digital  Data  Requirements 

•  Building  the  Government  Concept  of  Operations 
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•  Determining  data  types,  users,  and  functions 

•  Understanding  data  delivery,  format,  interchange,  and  delivery  options 
Module  4: 

•  Producing  a  Cohesive  RFP 

•  The  Solicitation  Process 

•  RFP  Development 

•  Data  Delivery  Considerations 

•  Acquiring  Technical  Orders 

•  Acquiring  Technical  Data  Packages 

•  SOO/SOW  Language 

•  Acceptance  and  Evaluation  Criteria 
Module  5: 

•  Conducting  Source  Selection 

•  Contractor  Proposal  Process 

•  Source  Selection  Process 
Module  6: 

•  Fielding  of  Digital  Data 

•  JCALS 

•  JEDMICS 
Module  7: 

•  Gleaning  from  Experience 

•  Digital  Data  Acquisition  Return  on  Investment 

•  Acquisition  Lessons  Learned 
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D.6  Software  Licensing 

In  addition  to  the  Adobe  Acrobat  Reader,  the  following  programs  have  obtained  the  appropriate 
software  licenses  for  viewing  digital  TOs: 

Program  Name  Browser  Name  Software  Vendor 

JSTARS  JMIS  Northrup  Grumman 

B-IB  Multi-Doc  Pro  CITEC 

AW  ACS  Multi-Doc  Pro  CITEC 


D.7  Air  Force  DTD  Repository 

Page-oriented  TOs  should  be  developed  in  SGML  format  with  the  appropriate  and  approved  Air 
Force  content  specific  DTD.  If  an  Air  Force  DTD  does  not  exist  for  a  particular  TO  type,  then 
the  contractor  should  produce  a  DTD  only  after  coordinating  its  development  and  approval  with 
the  Air  Force  PDSM  Program  Office,  which  maintains  the  AF  DTD  Repository. 

The  on-line  repository  is  available  through  the  Technical  Manual  Specifications  and  Standards 
(TMSS)  and  Digital  Support  Suites  (DSS)  system  at:  http://129.52.152.8/pub/tmss-Web/  alF 
all.htm 

To  access  DTDs  from  this  site,  select  the  specification  or  standard  number  for  which  you  wish  to 
view  the  DTD  and  you  will  be  given  a  menu  of  documents,  related  to  the  selected 
documentation. 

The  following  list  contains  the  DTDs  that  have  been  developed  for  legacy  data  to  be  used  on  the 
JCALS  system.  These  files  are  updated  frequently  on  this  site.  An  additional  FTP  site  has  been 
established  for  the  ALCs  to  access  sample  data.  To  find  out  the  most  current  version  or  for 
sample  data  in  accordance  with  these  DTDs,  contact  the  AF  PDSM  Office  or  Susan  Yucker  at 
(513)  257-2229  (email  yuckers@afcpo.wpafb.afmil). 

1.  MIL-D-87269,  Database,  Revisable:  Interactive  Electronic  Technical  Manuals,  for  the 
Support  of 

2.  MIL-L-803  IF,  List  of  Applicable  Publications  (LOAPs),  Preparation  of 

3.  MIL-M-5096F,  Manuals,  Technical:  Inspection  and  Maintenance  Requirements; 
Acceptance  and  Functional  Check  Flight  Procedures  and  Checklists;  Inspection  Work 
Cards;  and  Checklists;  Preparation  of 

4.  Legacy  MIL-M-5096,  Manuals,  Technical:  Inspection  and  Maintenance  Requirements; 
Acceptance  and  Functional  Check  Flight  Procedures  and  Checklists;  Inspection  Work 
Cards;  and  Checklists;  Preparation  of 


D-9 


5.  MIL-M-5288H,  Manuals,  Technical:  Cargo  Aircraft  Loading  and  Offloading,  Preparation 
of 

6.  MIL-M-5920F  (-5  Series),  Manuals,  Technical,  Sample  Basic  Weight  Checklists  and 
Loading  Data 

7.  MIL-M-7700F,  Manuals,  Flight 

8.  MIL-PRF-9854C,  Manuals,  Technical,  Structured  Repair  (Aircraft) 

9.  MIL-M-9977K,  Manuals,  Technical  and  Checklists:  Munitions/Weapons  Loading 
Procedures,  Nonnuclear  and  Nuclear  Packages,  Standard  Data:  Munitions  Loading 
Procedures,  Nonnuclear,  Preparation  of 

10.  Legacy  MIL-M-9977,  Manuals,  Technical  and  Checklists:  Munitions/Weapons  Loading 
Procedures,  Nonnuclear  and  Nuclear  Packages,  Standard  Data:  Munitions  Loading 
Procedures,  Nonnuclear,  Preparation  of 

1 1 .  MIL-PRF-9994C,  Manuals,  Technical,  Mobile  Training  Sets  and  Parts  Task  Trainers 
Operation  and  Maintenance  Instructions 

12.  MIL-M-38384D,  Manuals,  Technical  and  Checklists:  Weapon  Deliver  and  Aircrew 
Procedures,  Nuclear  and  Nonnuclear,  Preparation  of 

13.  MIL-M-38769D,  Manuals,  Technical:  Work  Unit  Code 

14.  Legacy  MIL-M-38769,  Manuals,  Technical:  Work  Unit  Code 

15.  MIL-M-38784C,  Manuals,  Technical:  General  Style  and  Format  Requirements 

16.  Legacy  MIL-M-38784C,  Manuals,  Technical:  General  Style  and  Format  Requirements 

17.  MIL-STD-38784,  Standard  Practice  For  Manuals,  Technical:  General  Style  and  Format 
Requirements 

18.  MIL-PRF-38804,  Time  Compliance  Technical  Orders,  Preparation  of 

19.  MIL-T-38804C,  Time  Compliance  Technical  Orders,  Preparation  of 

20.  MIL-PRF-38807C,  Manuals,  Technical:  Illustrated  Parts  Breakdown,  Preparation  of 

21.  MIL-M-38807B,  Manuals,  Technical:  Illustrated  Parts  Breakdown,  Preparation  of 

22.  Legacy  MIL-M-38807,  Manuals,  Technical:  Illustrated  Parts  Breakdown,  Preparation  of 

23.  MIL-PRF-38807C,  Performance  Specification,  Manuals,  Technical  -  Illustrated  Parts 
Breakdown,  Preparation  of 
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24.  MIL-M-83495B,  Manuals,  Technical:  On  Equipment  Set,  Organization  Maintenance 
Manuals;  Detailed  Requirements  for 

25.  Legacy  MIL-M-83495,  Manuals,  Technical:  On  Equipment  Set,  Organization 
Maintenance  Manuals;  Detailed  Requirements  for 

26.  MIL-PRF-83495B,  Manuals,  Technical:  On  Equipment  Maintenance  Manual  Set 
Preparation 

27.  MIL-PRF-87158B,  Manuals,  Technical,  Aircraft  Battle  Damage  Assessment  and  Repair 

28.  MIL-M-87929A,  Manuals,  Technical:  Operation  and  Maintenance  Instructions  in  Work 
Package  Format  (for  USAF  Equipment) 

29.  Legacy  MIL-M-87929,  Manuals,  Technical:  Operation  and  Maintenance  Instructions  in 
Work  Package  Format  (for  USAF  Equipment) 

30.  DRAFT  MIL-PRF-87929B,  Manuals,  Technical:  Operation  and  Maintenance  Instructions 
in  Work  Package  Format  (for  USAF  Equipment) 

D.8  Air  Force  Points  of  Contact 

Lt.  Col  John  M.  Eckerlv 

Single  Manager 
MSG/ILMP 

E-mail:  eckerly@pdgate01  .wpafb.af.mil 

Phone;  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Gail  P.  Brown 

Single  Manager 
MSG/ILMP 

E-mail:  brownfg@afcpo.wpafb.af.mil 

Phone;  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Major  Paul  Honk 

Technical  Director 
MSG/ILMP 

E-mail:  houkp@afcpo.wpafb.af.mil 

Phone:  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Harry  M.  Ray 

Chief,  Business  Management  Division 
MSG/ILMP 

E-mail:  rayh@afcpo.wpafb.af.mil 

Phone:  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 
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Michael  L.  Collier 


Chief,  JCALS  Implementation  and  TMSS  Division 
MSG/ILMP 

E-mail:  colliem@afcpo.wpafb.af.mil 

Phone:  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Bradley  S.  Sanders 

Chief,  Data  Management  Division 
MSG/ILMP 

E-mail:  sanders@afcpo.wpafb.af.mil 

Phone:  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Timothy  Sierer 

Chief,  JEDMICS  Implementation  Division 
MSG/ILMP 

E-mail:  sierert@afcpo.wpafb.af.mil 

Phone:  DSN:  787-3085  or  Commercial:  (937)  257-3085 

Fax:  DSN:  787-5881  or  Commercial:  (937)  2^7-5881 

Michael  L.  Collier 

Chief,  JCALS  Implementation  and  TMSS  Division 
MSG/ILMP 

E-mail :  coll iem@  afcpo .wpafb.af.mil 

Phone:  DSN:  674-0840  or  Commercial:  (937)  904-0840 

Fax:  DSN:  787-5881  or  Commercial:  (937)  257-5881 

Steve  Holloway 

JCALS/TMSS//IETM  Project  Lead 
DSN  787-8215  (937)  257-8215 
E-mail:  hollows@afcpo.wpafb.af.mil 
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APPENDIX  E 

NAVY  lETM  INFORMATION 


E.l  Background 

When  lETM  developments  began  in  earnest  in  the  early  1990s  NAVSEA,  NAVAIR  and 
SPAWAR,  as  well  as  many  individual  codes  within  each  command,  initiated  exploratory  lETM 
programs.  The  AEGIS  community  funded  and  developed  an  lETM  for  the  Radio 
Communication  Set  (RCS),  as  did  the  submarine  community  for  the  AN/BSY-2  Sonar  Set. 
Based  on  the  impressive  feedback  as  a  result  of  these  lETM  deployments,  NAVSEA  04  selected 
a  mature  Hull,  Mechanical  and  Electrical  equipment  program  to  prove  that  legacy  systems  could 
be  cost  effectively  migrated  to  Class  Il/ni  lETM  status.  The  LM2500  Gas  Turbine,  prime  mover 
for  many  of  the  Navy’s  surface  combatants,  was  selected  as  the  candidate  program.  Thousands  of 
pages  of  material  were  scanned,  placed  in  OCR  format  and  SGML  tagged.  View  packages  were 
built  from  the  resulting  SGML  instance  and  displayed  using  the  Info  Access  browser. 
Conversion  and  developmental  costs  were  within  acceptable  parameters,  and  positive  feedback 
was  obtained  through  demonstration  of  the  Gas  Turbine  Systems  lETM  within  the  Naval 
community. 

Individual  NAVSEA/SPAWAR  Program  Managers  converted  paper  technical  manuals  to  lETM 
format  to  avoid  potential  conflicts  and  inefficiencies.  NAVSEA  04  was  designated  as  the  central 
authority  for  digitizing  legacy  data.  Over  the  past  several  years,  nearly  a  million  pages  of 
technical  data,  including  drawings,  maintenance  data  and  operational  procedures  have  been 
digitized  in  the  form  of  SGML  and/or  raster  images.  The  data  is  stored  and  maintained  in  an 
SGML  relational  database  and  disseminated  on  CD-ROM  when  requested.  lETM  data  can  be 
viewed/printed  from  either  Adobe  Acrobat  or  the  D)matext  browser. 

NAVAIR  had  a  different  set  of  criteria  it  wanted  to  meet  when  converting  paper  to  SGML. 
NAVAIR  determined  it  needed  more  of  the  benefits  resulting  from  a  Class  ni/IV  lETM  to 
support  its  Advanced  Maintenance  Environment  [(AME),  formerly  AIMDD]  concept. 

For  new  systems,  the  overall  Navy  strategy  is  to  pursue  acquisitions  of  Class  IV/V  lETMs  when 
the  acquisition  cost  model  substantiates  financial  savings  over  the  life  cycle  of  the  weapon 
system.  For  the  conversion  of  legacy  systems,  refer  to  paragraph  E.3  of  this  Appendix. 

E.2  Compatibility  with  AXIS 

The  Advanced  Technical  Information  Support  (ATIS)  system  provides  software  that  performs 
library  functions  and  supports  the  display  of  all  Classes  of  digital  TMs.  Once  the  user  selects  a 
TM  to  view,  ATIS  locates  it  and  then  launches  the  appropriate  viewer  for  that  lETM.  ATIS 
provides  a  guaranteed  set  of  hardware  that  enables  lETMs  created  by  different  programs  to  be 
viewed  on  the  same  display  hardware,  minimizing  the  amount  of  unique  display  equipment. 
Additionally,  ATIS  and  a  240  CD  jukebox  will  be  available  on  Shipboard  Non-tactical  ADP 
(SNAP)  terminals  on  ships.  While  it  is  desirable  for  all  lETMs  to  be  compatible  with  ATIS,  it  is 
recognized  that  there  may  be  conditions  where  that  is  not  possible  or  practical;  for  example,  on 
lETMs  where: 
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•  Software  programming  is  integrated  into  the  weapon  system  operating  software. 

•  The  ATIS  software  constraints  and/or  restrictions  severely  impact  on  a  program  or  user  or 
preclude  a  specific  lETM  implementation  (cognizant  managers  should  be  aware  of  those 
restrictions  and  ensure  that  there  are  no  negative  impacts  from  them). 

If  for  any  reason  the  lETM  chosen  is  not  ATIS  compatible,  particularly  those  integrated  into  the 
weapon  system  or  equipment,  the  program  assumes  the  responsibility  for  roles  that  ATIS 
currently  fills  and  must  ensure  that  all  potential  legitimate  users  have  access  to  the  data. 
Directions  on  making  lETMs  ATIS  compatible  are  found  on  the  WWW  at 
http://navysgml.dt.navy.mil/  ietmdeve.html  or  by  contacting  the  ATIS  Help  Desk  identified  in 
paragraph  E.l  1  of  this  Appendix. 

E.3  Data  Conversion  Efforts 

Raster  TMs  have  two  mature  conversion  processes  in  place  at  NSWC,  Philadelphia  and  the 
Naval  Air  (NAVAIR)  Technical  Services  Facility  (NATSF).  Any  legacy  hard-copy  TM  should 
be  referred  to  these  sites  for  conversion.  Conversion  is  already  under  Government  contract  and 
programs  should  not  attempt  to  convert  legacy  TMs  into  this  raster  format  other  than  at  these 
conversion  sites.  In  many  cases,  NSWC,  Philadelphia  and  NATSF  may  be  funded  to  convert  the 
TMs  into  raster  format.  If  conversion  funds  have  not  been  allocated,  NSWC,  Philadelphia  and 
NATSF  will  be  able  to  quote  the  costs  of  converting  the  TMs  (Table  E-1). 


Table  E-1.  Cost  of  Conversion 


Interactivity 

Description 

Class 

Savings 

Cost/Page 

Low 

Raster  scanned  with  Indexing 

I 

Wt/Space 

$2 

Moderate 

Intelligent  (printable) 

II 

Wt/Space,  reduced 
access  time 

Good 

Interactive  to  user  (printable) 

III 

Wt/Space,  reduced 
access  time,  reduced 
data  set 

$10-25 

High 

Interactive  to  user  (objects) 

IV 

Wt/Space,  reduced 
access  time, 
minimized  data  set 

$40-  1004- 

Full 

Interactive  to  user  and  associated 
systems 

V 

Training  Fleet/Data 
Maintenance 

Integration 

$2004- 

NAVSEA,  NAVAIR,  and  SPAWAR  have  scanned  the  majority  of  existing  hard-copy  TMs. 
NSWC,  Philadelphia  or  NATSF  can  assist  the  program  in  determining  whether  required  TMs 
have  already  been  converted  into  this  Class  I/II  format  and  whether  the  configuration  of  the 
Class  I/II  lETM  is  current.  These  scanned  images  are  also  used  as  the  source  data  for  Technical 
Manual  Publish  On  Demand  System  (TMPODS)  that  provides  hard-copy  manuals  without  the 
need  to  store  excesses  or  dispose  of  obsolescent  material. 
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Step  1 :  Contact  NSWC  or  NATSF  to  initiate  Class  I  conversion  process. 

Step  2:  NSWC/NATSF  determine  whether  hard-copy  TM  is  a  raster  candidate  (e.g.,  front 

matter  indexing  in  basic  and  changes,  page  quality,  security  classification,  size  of  the 
TM,  and  whether  color  is  used  in  the  TM  all  determine  suitability  for  scanning). 

Step  3:  If  the  TM  is  not  a  Class  I/II  candidate,  decide  whether  conversion  of  the  TM  to  a 
higher,  more  costly  lETM  Class  is  justified. 

Step  4:  NSWC/NATSF  determine  if  funding  is  available  to  support  the  conversion. 

Step  5:  If  not,  NSWC/NATSF  provide  the  program  with  an  estimate  of  conversion  costs. 

Step  6:  Determine  whether  the  conversion  costs  are  acceptable. 

Step?:  If  the  conversion  costs  are  not  acceptable,  evaluate  the  costs  and  benefits  of 

converting  to  a  more  interactive  Class  of  lETMs. 

Step  8:  If  the  costs  are  acceptable,  send  the  TMs  and  necessary  funding  to  support 

conversion. 

Step  9:  NSWC/NATSF  will  return  the  converted  TM  on  the  agreed  upon  media. 

Step  10:  Procure  ATIS  software  from  NAVSEA  Logistics  -  Indian  Head  Detachment  and 
ensure  that  appropriate  display  hardware  exists  where  lETM  is  to  be  used. 

E.4  Navy  lETM  Display  Equipment 

Where  a  common  infrastructure,  such  as  the  Naval  Tactical  Command  Support  System  (NTCSS) 
exists  or  is  being  formed,  that  manager  will  be  responsible  for  ensuring  the  availability  of  items 
under  his  or  her  cognizance.  When  programs  decide  not  to  use  the  common  infrastructure  or 
develop  lETMs  that  will  not  effectively  play  on  the  common  architecture,  the  program  reinains 
responsible  for  display  equipment  availability  until  another  activity  assumes  full  responsibility, 
including  funding.  With  the  exception  of  NTCSS,  there  are  also  no  current  mechanisms  that 
require  programs  that  share  common  work  places  to  coordinate  the  use,  distribution,  and  support 
of  lETM  display  hardware.  It  is  imperative  to  do  so  in  order  to  minimize  the  costs  associated 
with  lETM  display  hardware  support,  as  well  as  minimizing  other  impacts  (e.g.,  space  onbo^d 
ship).  These  logistic  support  issues  must  be  evaluated  and  addressed  to  ensure  the  effective 
availability  of  the  lETMs  provided  by  the  minimum  number  of  units  at  reasonable  costs. 

Display  equipment  that  is  to  be  part  of  the  NTCSS  infrastructure  (SNAP  LAN)  will  follow  the 
procedures  established  by  NTCSS  (see  paragraph  E.ll  of  this  Appendix  for  the  appropriate 
points  of  contact).  These  procedures  include  certification  of  display  hardware  as  to  its  hardware 
and  software  compatibility  on  the  LAN.  NAVMASSO  and  NAVSEA  Automated  Data  Systems 
Activity  (SEAADSA)  support  NTCSS  in  performing  the  certification  process.  Once  certified, 
NTCSS  will  manage  the  sparing,  LAN  and  warranty  management  involved  with  the  displays. 
NTCSS  has  existing  display  hardware  acquisition  contracts  it  can  make  available  if  needed. 


E-3 


NAVAIR  has  also  released  a  performance  specification  for  PEDDs.  See  paragraph  E.  1 1  of  this 
Appendix  for  the  appropriate  points  of  contact. 

E.5  Development  Resources 

A  copy  of  the  Navy  lETM  Process  Plan  (S0005-AD-PRO-010),  signed  out  by  NAVSEA  and 
SPAWAR  in  December  1995,  is  available  at  http://calsric.crane.navy.mil/refinfo.htm.  This 
document  is  intended  to  instruct  and  guide  programs  in  the  development  of  lETMs  in  a  way  that 
provides  for  their  life-cycle  use  and  maintenance  within  the  Department  of  the  Navy 
infrastructure.  The  Navy  lETM  Process  Plan  is  to  be  used  by  NAVSEA  and  SPAWAR  programs 
in  the  acquisition  of  new,  or  conversion  of  existing  hard-copy,  technical  manuals  into  lETMs. 

E.6  Classroom  Instruction 

NSWC,  Port  Hueneme  regularly  provides  classroom  instruction  on  both  the  east  and  west  coasts, 
for  the  acquisition  and  development  of  Navy  technical  manuals,  including  lETMs.  Consult 
paragraph  E.  1 1  of  this  Appendix  for  the  appropriate  points  of  contact. 

E.6.1  Authoring  Instructional  Materials  (AIM) 

AIM  is  a  software  application  implemented  in  FY94  by  the  Chief  of  Naval  Operations  (OPNAV 
N75),  to  streamline  the  development,  maintenance,  and  management  of  formal  training  course 
materials.  These  training  materials  draw  heavily  on  and  refer  extensively  to  technical  data 
included  within  technical  manuals.  The  creation  of  this  data  in  or  conversion  of  this  data  to 
digital  formats  for  interactive  view  and  use  through  electronic  devices  introduces  the  potential 
for  substantial  savings  in  technical  data  maintenance  and  training  development  and  substantial 
benefits  from  more  efficient  and  effective  training.  It  also  mandates  the  need  for  concurrent 
development  of  products  to  ensure  that  all  requirements  can  be  filled  from  the  new  digital  data 
set.  AIM  provides  a  critical  automated  linkage  between  formal  course  material  and  lETMs.  The 
following  paragraphs  describe  the  AIM  program  and  discuss  the  interface  requirements  between 
AIM  and  lETMs. 

E.6.1.1  Introduction  to  AIM 

AIM  is  designed  to  automate  many  elements  of  the  ISD  process  and  to  ensure  uniform 
formatting  and  specification  compliance  of  all  required  products.  It  provides  for  a  highly 
effective  automated  process  which  includes  the  course  design,  development,  surveillance, 
maintenance,  and  production  of  formal  training  materials.  AIM  was  developed  by  the  U.S.  Navy 
and  now  has  more  than  200  systems  in  use  by  Naval  Education  and  Training  Command 
(NAVEDTRACOM),  PEO,  DRPM,  SYSCOM  and  other  Government  activities  with 
responsibility  for  curriculum  development.  AIM  produces  both  immediate  and  long-term 
benefits  by  reducing  the  time  and  cost  to  develop  and  maintain  training  materials  throughout 
their  life-cycle;  users  have  reported  an  average  time-savings  of  40  percent  for  curriculum 
development  and  maintenance. 

AIM  optimizes  instructional  material  development  processes  and  standardizes  training  products 
by: 
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•  Automating  the  format  and  production  standards  of  MIL-HDBK-29612  and 
NAVEDTRA  130/131 

•  Providing  specialized  software  to  design,  develop,  and  maintain  training  materials, 
including  the  conversion  of  existing  training  materials  to  proper  relational  database 
management  system  (RDBMS)  products 

•  Supporting  configuration  management  of  graphics  and  their  integration  with  text 

•  Connecting  AIM  data  with  other  training  related  databases  (e.g.,  LSAR,  test/test  item 
banks,  training  administrative  data,  technical  data)  to  streamline  the  exchange  of  training 
material  information 

•  Interfacing  with  Defense  Printing  Service  (DPS)  offices  to  enable  automated  publishing 
and  printing  of  training  materials 

•  Supporting  the  DoD  CALS  standards 

New  development  or  revision  of  training  material  production  typically  occurs  at: 

•  One  of  the  Navy's  centralized  training  material  development  units 

•  A  Navy  training  activity 

•  A  contractor  facility,  usually  as  a  part  of  a  SYSCOM  hardware  contract 

The  decision  to  use  in-house  resources  or  to  acquire  the  curriculum  is  a  Training  Support  Agent 
(TSA)  responsibility. 

E.6.1.2  AIM  System  Description 

The  AIM  System  provides  a  menu-based  interface  to  SMEs  and  training  materials  for 
developers.  By  guiding  the  user  through  menus,  it  allows  the  user  to  develop,  convert,  maintain, 
and  manage  training  materials.  The  menus  provide  requests  for  information,  for  background, 
and  support  of  training  materials  -  as  well  as  prompts  for  the  training  material  itself.  This 
interactive,  menu-driven  approach  to  develop  and  maintain  training  materials  provides  the  user 
with  much  faster  and  more  consistent  data  entry  than  manual  methods. 

The  AIM  System  uses  an  RDBMS  for  power  and  flexibility  in  organizing  and  accessing  the  data 
and  the  complex  relationships  between  each  element  stored.  It  simplifies  the  tasks  of  locating 
the  reusable  data  units  and  can  automatically  cross-reference  data  across  several  training  material 
products.  Life-cycle  surveillance  and  maintenance  is  achieved  with  a  menu-driven  user  interface 
and  automated  links  among  the  various  AIM  modules.  The  user  is  notified  of  all  potential 
impacts  of  maintenance  actions  to  all  other  related  training  materials,  thus  ensuring  that  each 
related  item  affected  by  a  change  is  kept  up-to-date.  Three  versions  -  AIM,  AIM  I,  and  AIM  n 
-  currently  comprise  the  overall  AIM  System  and  provide  compliance  with  current  Navy 
training  policy. 
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E.6.1.3  AIM  and  AIM  I 


Both  AIM  and  AIM  I  support  the  development  of  Personnel  Performance  Profile  (PPP)  based 
training  materials.  NAVEDTRA  131  (Personnel  Performance  Profile  Based  Curriculum 
Development  Manual)  provides  detailed  guidance  on  this  methodology.  PPP  was  originally 
designed  to  develop  training  programs  that  teach  operation  and  maintenance  of  hardware  systems 
or  equipment.  (This  methodology  is  advantageous  where  equipment  or  procedures  are  subject  to 
frequent  update  or  change.)  PPP-based  training  materials  rely  heavily  on  referenees  to  technical 
manual  data.  These  structural  references  are  inserted  in  the  curriculum  in  discussion  points  of 
the  lesson  plans  of  the  Instructor  Guide.  The  Trainee  Guide  typically  also  uses  technical  data 
references  on  Instruction  Sheets. 


AIM  I  transitions  the  PPP/Training  Path  System  (TPS)-based  AIM  into  the  graphic  user  interface 
(GUI)  environment.  AIM  I  is  a  MS  Windows'"’’^  based  product  that  takes  advantage  of  user 
friendly  software  and  promotes  a  “look-and-feel”  that  is  comfortable  and  familiar  to  nearly  all 
computer  users.  Training  materials  that  are  developed  and  maintained  in  accordance  with  MIL- 
HDBK-29612  and  NAVEDTRA  131  will  be  supported  by  AIM  I.  Output  products  of  AIM  I  are: 


•  Training  Project  Plan  (TPP) 

•  Curriculum  Outline  of  Instruction  (COI) 

•  Course  Master  Schedule  (CMS) 

•  Training  Course  Control  Document  (TCCD) 

•  Instructional  Media  Materials  (IMM) 


PPP  Table 
TPS 

Lesson  Plan  (LP) 
Trainee  Guide  (TG) 
Test  Items 


E.6.1.4  AIM  II 

AIM  II  supports  the  development  of  task-based  curricula.  The  task-based  ISD  process  was 
designed  to  develop  training  programs  that  teach  performance  of  a  job  or  function  where 
operation  or  maintenance  of  the  hardware  is  usually  incidental  or  secondary  to  actual 
performance  of  the  job.  Task-based  curriculum  uses  information  from  technical  manuals  even 
more  extensively  than  PPP  training.  Task-based  materials  not  only  used  structural  references  in 
related  instructor  activities  and  TG  Sheets,  but  frequently  incorporate  actual  portions  of  the 
material  (e.g.,  blocks  of  text  or  graphics)  directly  into  the  training  materials.  NAVEDTRA  130 
(Task  Based  Curriculum  Development  Manual)  provides  details  on  this  methodology. 

E.6.1.5  AIM-IETM  Automated  Interface 

The  automated  interface  with  lETMs  implemented  in  AIM  I  Rel  2.0  enables  the  training  material 
developer  to  browse  the  lETM  from  within  AIM  during  LP  and  TG  preparation.  The  developer 
can  also  create  automated  links  in  the  database  from  specific  LP  Related  Instructor  Activities 
(RIAs)  and  TG  Sheets  to  particular  points  in  the  DETM.  During  surveillance  of  training 
materials,  the  automated  interface  saves  major  time  for  curricula  staff  by  defining  precise 
differences  between  the  version  of  the  lETM  currently  used  in  training  materials  and  new 
versions.  It  then  pinpoints  all  of  the  courses  (down  to  the  RIA  and  TG  sheet  level)  in  which 
lETM  elements  changed  or  were  deleted  in  the  new  lETM  version.  This  reduces  the  curriculum 
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surveillance  task  from  literally  thousands  of  lETM  elements  to  be  manually  checked  to  less  than 
100  elements  based  on  the  analytical  tools  built  into  AIM  I  Rel  2.0. 

E.6.1J6  AIM  InripiemEiitati^ 

All  programs  interested  in  implementing  AIM  should  contact  the  Naval  Air  Warfare  Center 
Training  Systems  Division  (NAWCTSD).  The  Electronic  Training  Environment  (ETE)  Program 
of  NAWCTSD  also  administers  the  installation  of  automated  electronic  classrooms  and  learning 
resource  centers  in  Navy  activities.  Refer  to  paragraph  E.  1 1  of  this  Appendix  for  NAWCTSD 
points  of  contact. 

E.7  Training  Integration  Management  Software  (TIMS) 

E.7.1  Background 

TIMS  is  being  developed  as  part  of  a  larger  project  addressing  the  needs  of  an  automated 
classroom  developed  by  NAVSEA.  With  the  advent  of  new  electronic  media  replacing  paper 
technical  manuals  and  the  new  information  technologies  creating  opportunities  to  enhance 
training  and  maintenance  processes,  it  became  necessary  to  develop  a  common  graphical  user 
interface  (GUI)  that  makes  the  efficient  management  of  electronic  training  materials.  TIMS 
allows  schoolhouse  personnel  to  link,  deliver,  and  manage  a  variety  of  electronic  media.  Refer 
to  paragraph  E.l  1  of  this  Appendix  for  points  of  contact. 

TIMS  is  designed  to  work  in  a  Microsoft  Windows™  environment  bringing  together  various 
Windows-compatible  software  applications  to  ensure  efficient  link  and  delivery  of  electronic 
training  materials.  It  can  be  used  in  a  stand-alone  configuration  or  as  part  of  a  network 
configuration.  The  application  of  this  software  interface  creates  costs  savings  by  reducing 
instructor  preparation  time  and  life-cycle  maintenance. 

E.7.2  Objectives 

The  primary  objective  of  TIMS  is  to  enable  curriculum  developers  and  instructors  to  link  and 
deliver  a  variety  of  electronic  course  materials.  By  bringing  a  greater  variety  of  more  readily 
accessible  teaching  materials  into  the  classroom,  TIMS  should  enhance  learning.  The  TIMS 
GUI  enables  instructors  to  more  efficiently  perform  these  various  tasks,  while  conforming  to 
established  procedures. 

E.8  Software  Licensing 

SEA  04TD  has  considerable  experience  in  qualifying  and  licensing  lETM  related  software  tools 
for  wide  scale  application.  NAVSEA  (04TD)  has  agreed  to  act  as  the  software  clearinghouse  for 
programs  seeking  advice  and  assistance  concerning  licensing  issues.  Refer  to  Table  E-2  for  a 
brief  summary  of  existing  license  agreements. 
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Table  E-2.  Licensing  in  Place 


CLASS 

NOMENCLATURE 

STATUS 

I 

TMS  View  Director 

500  applications  in  Reet. 

Provided  with  ATIS 

II 

TMS  Master  View 

20,000  pages  converted  for  PIMS. 

20  viewers  currently  licensed. 

License  for  PHALANX  Close-In  Weapons  System  being 
negotiated 

II 

Electronic  Book 

Licensed  for  all  Programs  at  NSWC,  Philadelphia  and 

Technology 

NSWC,  Pt.  Hueneme. 

n 

Adobe  Postscript/Alliant 

3,000  pages  converted  by  VLS.  Fifteen  conversion 
license  available  for  NSWC,  Pt.  Hueneme  use. 

III 

InfoAccess 

Licensed  for  any  TAD  Program  at  NSWC,  Pt.  Hueneme. 

III 

IADS 

Government  Owned 

IV 

AIMSS 

Licensed  for  AEGIS  Fire  Control  Radar  Transmitter 

E.8.1  Navy  CALS  DTD  Repository 

The  Navy  CALS  Coordination  Office  tasked  the  David  Taylor  Model  Basin  (DTMB)  (Naval 
Surface  Warfare  Center,  Carderock  Division)  as  the  central  site  for  registration,  testing,  and 
distribution  of  Department  of  the  Navy  (DoN)  DTDs  (and  FOSIs,  where  applicable).  NSWC-CD 
is  only  responsible  for  DTDs  and  FOSIs  developed  in  compliance  with  MIL-PRF-28001  and 
MIL-PRF-87269  SGML.  NSWC-CD  established  the  Navy  CALS  DTD  Repository  to: 

•  Minimize  duplicative  DTD  investments 

•  Register  DTDs  and  tag  sets 

•  Perform  technical  testing  and  approval 

•  Coordinate  functional  testing  of  Navy  DTDs  and  FOSIs 

DTDs  are  complex  SGML  constructs  that  can  be  costly  to  develop.  NSWC-CD  maintains  an 
electronic  repository  of  DTDs  and  SGML  tags  and  constructs  for  re-use  by  Navy  activities  in 
implementing  digital  technical  manual  applications.  NSWC-CD  provides  technical  support  to 
Navy  activities  for  application  of  digital  interchange  technology  and  standards  in  support  of  the 
DoN  CALS  Program.  NSWC-CD  is  also  the  Navy  custodian  for  CALS  data  interchange 
specifications  and  has  extensive  experience  in  CALS  interchange  specifications  for  engineering 
data,  technical  manuals,  and  lETMs. 
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E.8.2  Available 


The  following  Navy  DTDs  can  be  retrieved  from  the  Navy  CALS  DTD  Repository: 

•  MIL-M-38784C  -  Manuals,  Technical;  General  Style  and  Format  Requirements 

•  MIL-M-8 1 927  -  Manuals,  Technical;  General  Style  and  Format  of  (Work  Package  Concept). 

•  MIL-M-8 1928  -  Manuals,  Technical:  Aircraft  and  Aeronautical  Equipment  Maintenance, 
Preparation  of  (W  ork  Package  Concept) 

•  MIL-M-8 1929  -  Manuals,  Technical:  Illustrated  Parts  Breakdown,  (Work  Package  Concept); 
Preparation  of 

•  MIL-PRF-87269,  Interactive  Electronic  Technical  Manuals  DataBase  (lETMDB)  DTD 

•  NAVSEA  C2  Revision  D  -  Naval  Sea  Systems  Command  Electronic  Technical  Manual 
'  Class  2,  DTD 

The  following  FOSIs  are  undergoing  development  in  the  Navy  and  can  be  accessed  through  the 
Repository: 

•  NSWCCD-SSES  Engineering  Operational  Sequencing  System  (EOSS  DTD) 

—I  ArborText  Adept  Series  FOSI 

-1  INSO  DynaText  Style  Sheets 

•  Fleet  Technical  Support  Center  Planned  Maintenance  System  (FTSC  PMS  DTD) 

—1  INSO  DynaText  Style  Sheets 

To  facilitate  rapid  distribution  of  information,  the  CALS  DTD  Repository  can  be  accessed  via 
the  Internet,  the  WWW,  anonymous  FTP,  e-mail,  and  U.S.  Mail.  The  information  provided  on 
the  NSWC-CD  WWW  server  includes: 

•  Approved  Navy  SGML  DTDs  and  FOSIs 

•  Navy  SGML  Baseline  Tag  Set 

•  Navy  CALS  Reports  and  Technical  Memoranda 

•  CALS  Standards  Information 

•  lETM  Information  (Standards  and  current  research  efforts) 

•  Links  to  other  pertinent  on-line  repositories 
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•  Information  on  emerging  and  de  facto  standards 
E.9  Access  to  the  Navy  DTD  Repository 
E.9.1  World  Wide  Web  (WWW) 

The  WWW  provides  the  most  “user-friendly”  connection  to  the  Repository.  WWW  pages  guide 
the  user  through  hyperlinks  to  desired  information.  The  WWW  URL  address  for  the  Navy 
CALS  DTD  Repository  is: 

•  http://navycals.dt.navy.mil/dtdfosi/repository.html 

E.9.2  Anonymous  FTP 

The  DTDs  installed  in  the  Navy  DTD  Repository  may  also  be  retrieved  via  the  “anonymous 
guest”  FTP  protocol.  The  pub  directory  contains  the  files  associated  with  the  Navy  CALS  DTD 
Repository.  The  Internet  address  for  the  FTP  Repository  is: 

•  ftp://navycals.dt.navy.mil/pub/dtd/ 

E.9.3  E-mail 

Information  in  the  Navy  CALS  DTD  Repository  may  be  requested  by  an  e-mail  message.  The 
request  will  automatically  be  sent  to  the  appropriate  person  and  the  requested  information  will  be 
sent  to  register  electronically.  The  e-mail  address  is: 

•  webmaster@navycals.dt.navy.mil 

E.9.4  Telephone  or  Mail 

Requests  may  also  be  sent  to  DTMB  either  by  phone  or  U.S.  mail  at: 

Advanced  Information  Systems  Branch,  Code  183 

Naval  Surface  Warfare  Center 

Headquarters,  Carderock  Division 

Bethesda,  Md.  20084-5000 

Telephone:  (301)  227-3348 

DSN  287-3348 

E.IO  CD  Guidelines 

For  compatibility  with  ATIS  systems,  network,  and  jukebox,  CDs  should  be  tested  at  NAVSEA 
Logistics  -  Indian  Head  Detachment,  prior  to  replication.  The  Navy  CALS  website, 
http://navycals.dt.navy.mil/,  contains  information  related  to  ATIS  and  CD-ROM  publication. 
Refer  to  the  following  paragraph  for  points  of  contact. 
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E.ll  Points  of  Contact 


The  following  personnel  can  be  used  by  contractor  and  Government  programs  alike  in  seeking 
advice  in  the  issues  and  processes  associated  with  comparing  the  features  of  each  of  the  listed 
lETM  software  packages. 


Table  E-3.  Available  Subject  Matter  Experts 


Mi  1 

I 

TMS  View  Director  (AXIS) 

Andy  Kelly  SEA  04TD 

703  602-1060 

n 

TMS  Master  View 

Chester  Ellswick  NSWC- 
Louisville 

502  364-6406 

III 

IADS 

205  876-8112 

II 

Adobe  Postscript/Hercules 

Jim  Moses  NSWC-PHD 

805  982-8170 

III 

Info  Access 

Marty  Cohen  NSWC-CD-SSES 
Jim  Moses  NSWC-PHD 

215  897-1233 

II 

Electronic  Book  Technology 

Marty  Cohen,  NSWC-CD-SSES 

805  982-8170 

IV 

AMSS 

Ramona  Braun  NSWC-PHD 

805  982-0746 

Questions  or  Comments  on  the  Navv  lETMPP 

Wayne  Honea  -  NSWC-PHD  (5B20) 

Chair  of  Navy  Technical  Manual  Working  Group 
Internet:  honea_wayne@om.nswses.navy.mil 
DSN  55 1 -297 1  (805)  982-297 1 

DisUal  Data  Specifications  and  Standards 
MIL-PKF-87269 

Mr.  Joe  Fuller  -  NSWC-CD  (Code  182) 

Internet:  fuIler@oasys.dt.navy.mil 
DSN  287-1358  (301)  227-1358 

MIL-PRF-28001 

Mr.  Joe  Gamer  -  NSWC-CD  (Code  183) 
Internet:  gamer@oasys.dt.navy.mil 
DSN  287-1533  (301)227-1533 

DTD  Re2istration  and  Guidance 

Mr.  Joe  Gamer  -  NSWC-CD  (Code  183) 
Internet:  gamer@oasys.dt.navy.mil 
DSN  287-1533  (301)  227-1533 
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Status  of  Specification  and  Standards  Waivers 
NAVSEA 

Mr.  Mickey  Ander  -  SEA  04TD  (Code  04TD31) 
Internet:  ander_mickey@hq.navsea.navy.mil 
DSN  332-8700  (703)  602-8700 

NAVAIR 

Mr.  Tom  Martin  -  NATSF  (Code  3.3D) 

Internet:  thomas_martin@natsfgw.natsf.navy.mil 
DSN  442-2924  (215)  697-2924 

Trackine  of  lETMS/CD-ROMs 
NAVAIR 

Mr.  Rich  Rizzo  -  NATSF  (Code  3.3. 1.5) 

Internet:  richard_rizzo@natsfgw.natsf.navy.mil 
DSN  442-5302  (215)697-5302 

NAVSEA/SPAWAR 

Ms.  Carrie  Ganzman  -  NSWC-PHD  (Code  5B62) 
Internet:  ganzman_carrie@om.nswses.navy.mil 
DSN  551-3141  (805)982-3141 

Mr.  Bob  Uehlein  -  NSWC-PHD  (Code  5B32) 
Internet:  uehlein_bob@om.nswses.navy.mil 
DSN  55 1  -2964  (805)  982-2964 

MEDIA  Identification  Numbers  (e.e.  CD  IDs) 
NAVSEA/SPAWAR 

Mr.  Bob  Uehlein  -  NSWC-PHD  (Code  5B32) 
Internet:  uehlein_bob@om.nswses.navy.mil 
DSN  551-2964  (805)982-2964 

NAVAIR 

Mr.  Rich  Rizzo  -  NATSF  (Code  3.3. 1.5) 

Internet:  richard_rizzo@natsfgw.natsf.navy.mil 
DSN  442-5302  (215)  697-5302 

lETM  Identification  Numbers 
NAVSEA/SPAWAR 

Ms.  Tona  Martinez  -  NSWC-PHD  (Code  5B61) 
Internet:  martinez_tona@om.nswses.navy.mil 
DSN  55 1  -3 1 68  (805)  982-3 1 68 

NAVAIR 

Mr.  Rich  Rizzo  -  NATSF  (Code  3.3. 1.5) 

Internet:  richard_rizzo@natsfgw.natsf.navy.mil 
DSN  442-5302  (215)  697-5302 
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Technical  Manual  Contract  Requirements 
NAVSEA/SPAWAR 

Mr.  Alan  Hatmaker  -  NSWC-PHD  (Code  5B61) 

Internet:  hatmaker_alan@om.nswses.navy.mil 
DSN  551-3159  (805)982-3159 

NAVAIR 

TMCR  Guidance  Document  available  from  NAVAIR  TM  Working  Group: 
Debby  Young  -  Chair  NAWCWD  (Code  3.3.1) 

Internet:  young® tecnetl  .jcte.jcs.mil 
DSN  35 1  -6576  (805)  484-6576 

NAVSEA  lETM  Software  Licensine  Coordinator 

SEA  04TD  -  George  White 

Internet:  white_george@hq.navsea.navy.mil 

DSN  332-8700  (703)  602-8700 

Paver  or  Electronic  TPDRs/TMDERs 
NAVAIR 

NATSF  Code  3.3. 1.2-  Attention:  John  Malloy 
Internet:  John_molloy@  natsfgw.natsf.navy.mil 
DSN  442-5307  (215)  697-5307 

NAVSEA/SPAWAR 

Mr.  Mike  Snavely  -  NSWC-PHD  (Code  5B30) 

Internet:  snavely_mike@om.nswses.navy.mil 
DSN  551-2970  (805)  982-2970 

TIDES  Electronic  TMDERS  forwarded  to: 

NAVSEA/SPAWAR 

tides@log04.nswses.navy.mil 

lETM  Electronic  Display  Requirements 
NAVAIR  (PEDDs) 

Mr.  John  Baranowski  -  NAVAIR  (Code  3.6.4)  Processes  Branch 
Internet:  baranowskijj.jfk@navair.navy.mil 
DSN  664-3090  x4183  (703)  604-3090  x41 83 

NAVSEA 

Mr.  George  White  -  NAVSEA  (Code  04TD34) 

Internet:  white_george@hq.navsea.navy.mil 
DSN  332-8700  (703)  602-8700 
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ATIS/IETM  Manaeement  Interfacine 
NAVSEA/SPAWAR 

Mr.  Andy  Kelly  -  NAVSEA  Logistic  Indian  Head  Det.  (Code  092) 

Internet:  kelly_william@hq.navsea.navy.mil 
DSN  332-0076  (703)  602-0076  x202 

NAVAIR 

Mr.  John  Baranowski  -  NAVAIR  (Code  3.6.4)  Processes  Branch 
Internet:  baranowskijj.jfk@navair.navy.mil 
DSN  664-3090  x4183  (703)  604-3090  x41 83 

ATIS  Help  Desk 
301-743-4911 

ATIS  IETM.NDX  Web  Location 
http://navysgml.dt.navy.mil/repository.html 

NTCSS  (SNAP  Network)  Interfacine 

Mr.  Pete  Davenport  -  Shipboard  Non-tactical  ADP  (SNAP)  Program  Office 

Internet:  davenpop@smtp-gw.spawar.navy.mil 

(703-602-0814) 

NALCOMIS  Functional  Requirements 

Mr.  Bill  Booth  -  NAVAIR  (Code  3.6.2)  Logistics  Information  Systems  Division 

Internet:  boothwc.jfk@navair.navy.mil 

DSN  664-3090  x41 26  (703)  604-3090  x41 26 

Automated  Electronic  Classrooms 
Mr.  Ben  Aaronson  -  NAWCTSD 
Internet:  AaronsonBA@navair.navy.mil 
DSN  960-  (407)  380- 

Trainins  Inteeration  Manaeement  Software 

Mr.  Tim  Tate  -  NAVSEA  (Code  042) 

Internet:  tate_timothy@hq.navsea.navy.mil 
DSN  224-5438  (703)614-5438 

Authorine  Instructional  Materials  (AIM) 

Mr.  Alan  Litz  -  NAWCTSD 
Internet:  LitzAD@navair.navy.mil 
DSN  960-8607  (407)  38 1  -8607 


E-14 


APPENDIX  F 

ARMY  lETM  INFORMATION 


Note:  The  Army  classifies  any  manual  less  than  a  Class  III  as  an  ETM.  This  notation  has  been 
preserved  for  this  appendix  only. 

F.l  lETM  Strategy 

The  U.S.  Army  lETM  Strategy  is  to  identify,  develop,  and  fund  lETMs  that  contribute  the 
greatest  potential  for  cost  saving  efficiencies  while  improving  the  mission  readiness  of  the 
weapon  and  C4I  systems  in  Force  XXL  The  Army's  goal  is  to  establish  management  structure 
and  evaluation  criteria  that  will  accelerate  lETM  implementation  to  derive  maximum  benefits 
from: 

•  Reduced  weapon  system  maintenance  costs  and  time 

•  Increased  weapon  system  availability 

•  Reduced  training  costs  and  course  lengths 

•  Improved  repair  technician  performance,  quality,  and  efficiency 

•  Reduced  costs  to  author,  deliver,  manage,  and  update  TM  information 

•  Capability  to  transmit  to  remote  locations. 

F.2  Digital  Conversion  Efforts 

The  Army’s  electronic  technical  manual  effort  began  when  the  Deputy  Chief  of  Staff  for 
Logistics  (DCSLOG)  initiated  an  ETM  initiative  in  the  3rd  and  4th  Infantry  Divisions  (ID) 
(Mechanized)  and  their  Corps  trace.  With  nearly  30,000  maintenance  publications  in  circulation, 
this  initiative  represents  an  entirely  new  methodology  with  which  technical  information  is 
configured,  distributed,  accessed  and  updated.  ETMs  provide  the  Army,  civilian,  and  contract 
maintenance  technicians  with  a  CALS  compatible  representation  of  the  instructions  for 
installation,  operation,  maintenance,  training  and  support  of  weapon  systems,  weapon  systems 
components,  and  support  equipment.  Users  have  access  to  technical  manuals,  technical  bulletins 
(TB),  supply  bulletins  (SB),  lubrication  orders  (LO),  maintenance  work  orders  (MWO)  and  other 
maintenance  documents  electronically  via  compact  disk-equipped  desktop  or  portable  personal 
computers  (which  include  notebooks  and  cruisepads). 

The  digital  conversion  process  involves  scanning  the  paper  TM  pages  and  applying  optical 
character  recognition  software  to  create  a  portable  document  file  (PDF).  Once  in  the  PDF  format, 
hypertext  links  are  applied  to  enable  soldiers  to  maneuver  through  the  electronic  book  faster  than 
through  the  paper  version.  It  allows  for  quick  access  to  specific  pages,  figures,  tables,  and  other 
related  TMs.  These  files  are  then  stored  on  CDs  where  they  can  be  accessed  by  an  Adobe 
Acrobat  that  resides  on  each  CD;  this  makes  it  usable  on  any  computer  with  a  CD  reader.  In 
addition,  ETMs  are  configured  by  weapon  system  and  include  all  related  TMs  for  ordinance  and 
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communication  sub-systems.  The  ETMs  are  to  be  distributed  using  the  U.S,  Army  Publishing 
Agency  (USAPA)  system. 

The  current  Army  strategy  is  to  continue  to  print  paper  maintenance  manuals  and  paper  changes 
for  unit-level  and  higher  pubs  for  those  who  want  them.  In  the  future,  when  CDs  and  other  media 
are  more  accepted,  paper  may  be  ended  or  in  limited  availability  for  20  manuals  and  higher. 
Operator  manuals  will  continue  to  be  printed  on  paper,  even  if  they  are  part  of  an  electronic 
manual. 

Two  types  of  CDs  will  be  produced.  One  will  have  major  end  items  or  weapons  systems, 
including  pubs  on  their  components.  A  second  type  will  cover  common-use  equipment  or  general 
subject  matter. 

ETMs  are  only  the  first  step  towards  automating  the  Army’s  maintenance  facilities.  The 
evolution  is  towards  BETMs,  which  are  already  in  the  process  of  development  by  several 
agencies  throughout  the  Army.  The  lETM  strategy  is  based  on  the  assumption  that  technical  data 
acquired  for  new  and  major  product  improvements  will  be  in  digital  format.  The  conversion 
effort  will  utilize  the  editable  word  processing  file  which  is  a  by-product  of  the  PDF  conversion 
efforts. 

F.3  lETM  Display  Equipment  (SPORT) 

Since  Army  ETMs  reside  on  a  platform-independent  CD,  several  different  computer  options  can 
be  used  to  meet  user  display  requirements.  The  Logistics  Integration  Agency  is  currently  testing 
the  program  using  both  notebook  computers  and  wireless  high  frequency  local  area  networks 
(CmiseLANs).  The  CruiseLAN  system  allows  several  mechanics  to  simultaneously  access 
different  ETMs  located  on  a  central  server,  utilizing  individual  wireless  dumb  terminals  (Cruise 
Pads)  (Figure  F-1). 

Through  a  prototype  software  interface,  known  as  Electronic  Technical  Manual  -  Interactive 
(ETM-I),  mechanics  can  also  electronically  transfer  parts  request  information  and  work  order 
data  between  the  ETM  platform  and  the  Unit  Level  Logistics  System  (ULLS)  and  the  Standard 
Army  Maintenance  System  (SAMS).  The  interface  not  only  cuts  down  on  extensive  data  entry, 
but  eliminates  transposition  errors  that  could  lead  to  faulty  requisitions  and  excess  parts. 

ETMs  are  currently  in  use  at  Fort  Hood,  Fort  Carson,  Fort  Stewart,  Fort  Campbell,  the  National 
Training  Center,  and  a  few  National  Guard  sites.  There  have  been  54  CruiseLAN  systems  and 
almost  1000  multimedia  computer  notebooks  fielded  in  support  of  the  ETM  program.  The  type 
of  platform  used  varies  by  location,  as  the  hardware  was  tailored  to  the  individual  units.  To  date, 
several  CDs  have  been  distributed  to  the  selected  units.  In  the  coming  months,  CDs  will  continue 
being  distributed  to  units  at  the  rate  of  several  new  weapon  systems  per  month. 
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Figure  F-1.  Army  lETM  Display  Equipment 
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F.4  Development  Resources 

MIL-STD-2361  establishes  SGML  requirements  for  use  in  Army  digital  publications.  Within  the 
standard,  Army  publications  SGML  requirements  are  separated  by  publication  types.  There  are 
specified  sections  for  administrative  publications,  training  and  doctrine  publications,  and 
technical  and  equipment  publications.  This  initial  publication  of  the  standard  contains  the  SGML 
requirements  for  Army  Technical  Manuals.  They  were  developed  in  accordance  with  the 
functional  requirements  contained  in  MIL-STD-40051  (Technical  Manual  Preparation).  The 
SGML  requirements  for  technical  equipment  publications  are  applicable  for  the  development, 
acquisition,  and  delivery  of  ETM/IETMs.  Specific  ETM/IETM  functionality  (e.g.,  display  and 
database  requirements),  currently  contained  in  MIL-PRF-87268  and  MIL-PRF-87269  will  be 
included  in  future  revisions  to  MIL-STD-2361.  Subsequent  versions  of  MIL-STD-2361  will 
contain  the  SGML  requirements  for  all  other  Army  publications,  developed  in  accordance  with 
their  respective  functional  requirements  documents. 

Additionally,  the  Guide  to  Contracting  for  Technical  Information,  AMC  pamphlet  25-35,  can  be 
downloaded  from  http://www.amc.army.mil/amc/ci/pub_index.htm.  The  pamphlet  contains 
language  for  inclusion  when  preparing  a  SOW  to  acquire  an  ETM/IETM  from  a  contractor. 
Specifically,  unless  you  are  acquiring  a  Class  III  lETM  or  higher  is  being  acquired,  the  SOW 
must  require  the  contractor  to  deliver  the  technical  manuals  in  PDF.  PAM  25-35  also  requires  the 
ETM/IETM  contractor  to  develop  a  quality  assurance  plan  in  accordance  with  ISO  9001.  In 
doing  so,  the  contractor  should  address  validation  and  verification  of  the  ETM/IETM,  including 
the  furnishing  of  display  equipment  during  Validation  &  Verification  (V&V). 

To  keep  up  with  the  latest  in  Army  ETMS/IETMs,  subscribe  to  the  Army’s  ETM  Bulletin  at 
http://www.logsa.army.mil/pubs.htm. 
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The  USAPA  Web  site,  http://www.usapa.amiy.mil,  allows  Army  personnel  to  electronically 
order  many  publications  pertaining  to  Army  information  products. 

The  LOGSA  lETM  Management  Plan,  dated  April  1997,  is  available  from  Mr.  John  Zibell 
(jzibell@logsa.army.mil).  The  EETM  Management  Plan  is  separated  into  three  sections: 

•  Section  I,  Management  -  Defines  the  actions  required  to  establish  and  assign  ETM/IETM 
related  responsibilities  to  the  Army  commands,  activities  and  Project  Managers.  It  also 
defines  the  actions  to  charter  a  body  of  SMEs  for  the  coordination  of  ETM/IETM  issues, 
establish  teams  to  review  ETM/IETM  related  products/tools  and  provide  recommendations. 

•  Section  II,  ETM/IETM  Related  Policy,  Guidance  and  Development  Procedures  for  Army  and 
Tri-Service  Initiatives  -  Defines  the  capabilities  that  are  or  will  be  available  to  aid  technical 
publication  and  weapon  system  managers  in  preparing  and  procuring  ETMs/IETMs. 

•  Section  III,  Funding  Requirements  -  This  section  was  to  define  the  Army’s  efforts  to 
identify,  develop  and  fund  for  ETM/IETM  efforts  that  contribute  the  greatest  potential  for 
cost  saving  efficiencies  while  improving  mission  readiness.  However,  only  a  list  of  Army 
lETM  candidates  is  included  in  this  section. 

The  Army  Doctrine  and  Training  Digital  Library  (ADTDL)  can  be  accessed  at 
http://155.217.58.58.  The  site  provides  a  globally  accessible  digital  repository  of  Army  doctrine, 
training  knowledge  sets,  and  interactive  applications  to  support  the  training  of  individuals  and 
units. 

The  site  also  supports  normal  library  functions,  maintains  a  library  information  catalog,  provides 
a  help  desk  and  bulletin  board,  and  transmits  requested  information.  Additionally,  it  offers 
information  such  as  doctrinal  literature  (e.g.,  field  manuals),  that  have  been  digitized  and 
converted  to  HTML  format.  In  the  future,  the  library  will  be  expanded  to  include: 

•  Multimedia 

•  Interactive  courseware 

•  Training  Support  Packages  (TSP)  containing  structured  situational  templates  for  planning, 
preparing  for,  and  conducting  training 

•  Information  relating  to  Training  Aids,  Devices,  Simulations  and  Simulators  (TADSS) 
available  to  support  training 

•  Unprocessed  After  Action  Review  (AAR)  information  from  Combat  Training  Center  (CTC) 
unit  rotations,  major  exercises,  and  operational  missions 

•  Lessons  learned  derived  from  processed  and  analyzed  AAR  information  resident  in  the  Army 
Historical  Archives  System  (AHAS) 
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F.5  Software  Licensing 

The  Army  uses  Acrobat  Reader  and  the  IADS  browser  as  delivery  vehicles  for  their  ETMs. 

F.5.1  Interactive  Authoring  and  Display  System  (IADS) 

The  IADS  application  provides  an  authoring  environment  for  interactive  and  integrated 
electronic  documents.  It  is  part  of  a  MICOM  initiative  designed  to  reduce  or  eliminate  the 
massive  duplication  of  paper  inherent  in  the  current  process  throughout  DoD.  IADS  contains 
several  software  modules  designed  to  support  the  development,  sustainment,  and  navigation  of 
CALS  compatible  hypertext  documents.  The  software  is  currently  in  use  world-wide. 

IADS  allows  users  to  build  or  edit  documents  using  SGML  tags  and  embed  or  reference  graphics 
using  the  CALS  Raster  CCITT  Group  4  or  Vector  (Computer  Graphics  Metafile  -  CGM)  files. 
Several  industry  graphics  standards  are  supported  as  well.  IADS  is  designed  as  a  Class  III 
environment,  but  is  capable  of  doing  Class  V  diagnostic  and  expert  system  integration.  It  also 
allows  Class  I  and  II  environments  for  static  documents.  A  database  application  for  electronic 
Repair  Parts  and  Special  Tools  List  (RPSTL)  or  IPB  database  is  also  included  in  the  software 
suite. 

While  the  original  concept  of  IADS  was  to  support  lETMs  developed  within  the  U.S.  Army,  the 
robust  nature  of  the  environment  has  allowed  all  services  to  use  IADS  in  a  variety  of 
applications. 

The  tool  is  Government-owned.  Although  the  software  is  free,  there  is  currently  an  optional 
$7,500  fee  for  training  and  in-depth  technical  support.  In  addition,  the  user  will  receive  all 
software  and  documentation  upgrades  as  well  as  access  to  the  IADS  Help  Line. 

F.6  Army  SGML  Registry  and  Library  (ASRL)  for  DTDs 

The  USAPA  has  established  the  Army  SGML  Registry  and  Library  (ASRL),  which  provides 
approved  DTDs  based  on  MIL-STD-2361  and  MIL-STD-40051  constructs  for  reuse  by 
Government  activities  and  their  contractors. 

DTDs  are  complex  SGML  constructs  that  can  be  costly  to  develop  and  will  probably  involve  a 
long  lead  time  for  approval.  The  ASRL  has  been  established  to: 

•  Minimize  duplicative  DTD  investments 

•  Register  DTDs  and  tag  sets 

•  Perform  technical  testing  and  approval 

•  Coordinate  functional  testing  of  DTDs  and  FOSIs 

The  WWW  site  address  for  the  ASRL  is:  http://www.asrl.com/ 
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DTDs  currently  available  are  (as  part  of  MIL-STD-2361  and  MIL-STD-40051): 


•  Technical  Manual  Assembly  Information  Chapter  (Production) 

•  General  Information  Chapter  (GIM) 

•  Maintenance  Information  Chapter  (MIM) 

•  Operator’s  Information  Chapter  (OPIM) 

•  Repair  Parts  and  Special  Tool  Lists  Information  Chapter  (RPSTL)  (PIM) 

•  Aircraft  Operator’s  Instruction  and  Checklist  Information  Chapter  (PILOT-OPIM) 

•  Preparation  of  Aircraft  for  Shipment  Information  Chapter  (SHIPIM) 

•  Supporting  Information  Chapter  (SIM) 

•  Troubleshooting  Information  Chapter  (TIM) 

It  should  be  noted  that  MIL-STD-2361  and  40051  are  presently  geared  for  page-oriented  lETMs. 
However,  with  a  minimum  of  creativity,  these  DTDs  can  be  modified  for  use  with  data-oriented 
lETMs. 

F.7  Army  Points  of  Contact 

Technical  Pubs 

Ms.  Judy  Brissom 

DSN  645-9843  (256-955-9843) 

jbrisson@logsa.army.mil 

Dean  Despelder 

DSN  645-9844  (256-955-9844). 

Ddespeld@logsa.army.mil 

Mr.  John  Zibell 

DSN  645-9833  (256-955-9833) 
jzibell@  logsa.  army.mil 

IADS  Ordering  and  Information 

Mr.  Rich  Gramly 

DSN  746-8 1 1 2  (205-876-8 1 1 2) 

rgramly@redstone.army.mil 
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APPENDIX  G 

USMC  lETM  INFORMATION 


G.l  Introduction 

The  Marine  Coip  lETM  acquisition  strategy  closely  mirrors  that  of  the  Army:  purchase  SGML 
but  deliver  digital  data  in  PDF.  This  is  in  part  due  to  the  similar  operational  mission  profiles 
shared  by  the  two  services  that  result  in  an  increase  in  the  amount  of  shared  equipment.  Since  the 
Army  is  the  life-cycle  manager  on  the  majority  of  the  shared  equipment  and  therefore 
responsible  for  the  technical  publications,  the  Marine  Corps  did  not  want  to  choose  a  different 
and  possibly  incompatible  digital  data  delivery  and  sustainment  system. 

G.2  USMC  Policy 

In  FY99,  the  Marine  Corps  plans  to  issue  a  new  acquisition  and  policy  guidance  document  on 
lETMs.  (This  document  may  be  a  chapter  or  appendix  to  the  USMC’s  overall  acquisition 
strategy.)  The  draft  version  of  the  USMC’s,  Integration  of  Information  Technologies  into  the 
Marine  Corps  Supply  and  Maintenance  Infrastructure,  will  address  the  following: 

•  Define  how  the  levels  of  lETMs  can  support  the  diverse  types  of  equipment  requiring 
maintenance  in  the  Marine  Corps 

•  Identify  how  lETMs  should  be  integrated  into  the  business  practices  within  the  maintenance 
community 

•  Define  how  the  integration  of  an  lETM  can  support  a  simplified  user  interface  and  thereby 
streamline  data  input 

•  Identify  interfaces  between  lETM  information  technologies  (AIT,  TMDE,  onboard  vehicle 
systems)  and  logistics  systems  (ATLASS,  TC-AIMS  II) 

G.3  Digital  Conversion  Efforts 

For  the  past  few  years,  MARCORSYSCOM  (PSD)  has  been  converting  many  USMC  legacy 
documents  to  PDF  format.  At  the  end  of  FY98,  the  Marine  Corps  have  converted  nearly  2,200 
technical  publications  for  online  distribution.  These  documents  are  available  at 
http://www.pubs.ala.usmc.mil,  which  is  a  Marine  Corps  Web  site  hosted  by  the  Marine  Corps 
Logistics  Base  in  Albany,  Georgia.  Access  is  restricted  to  those  personnel  trying  to  access  the 
site  with  a  .mil  IP  address.  For  SGML  source  data,  the  Marine  Corps  is  a  heavy  user  of  the  IADS 
software  (see  Appendix  A).  IADS  documents  can  be  viewed  over  the  Web  with  specialized  third 
party  software  (Citrix  Winffame).  Interested  parties  should  contact  Greg  Ransom 
(ransomga@quantico.usmc.mil)  for  more  information.  Efforts  are  currently  underway  to  make 
IADS  capable  of  interpreting  XML  files.  Additional  USMC  efforts  include  an  lETM  built  for  the 
TAOM  program,  which  has  used  MediaLynk,  a  Class  III  software  program  from  PRC/Litton. 
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G.4  Development  Resources 

Potential  USMC  lETM  developers  should  first  check  with  MARCORSYSCOM  (PSD)  prior  to 
committing  resources  to  lETM  development.  MARCORSYSCOM  (PSD)  will  provide  guidance 
to  the  Program  Manager  for  the  acquisition  of  digital  data  and  check  with  the  proper  Army 
personnel  if  the  original  technical  publication  was  obtained  from  the  Army.  MARCORSYSCOM 
(PSD)  will  also  make  recommendations  to  the  Program  Manager  for  the  type  of  ETM/IETM  to 
support  the  weapon  system/equipment.  Keep  in  mind,  ETM/IETM  data  procured  must  be 
compatible  with  Government  furnished  software  (IADS).  IADS  can  be  provided  to  defense 
contractors  by  sending  a  request  to: 

Commander  USAMICOM 

ATTN:  AMSMI-MMC-LS-SA 

Redstone  Arsenal,  AL  35898-5238  DSN  746-4024 

or 

Downloaded  from  the  Web  at  http://darkside.redstone.army.mil/ 

G.5  USMC  lETM  Acquisition  Policy  and  DTD  Guidance 

The  Marine  Corps  philosophy  for  lETM  acquisition  is  to  procure  SGML  marked  up  in 
accordance  with  MIL-PRF-28001  or  MIL-D-87269.  In  practice,  the  SGML  should  be  tagged  to 
the  IADS  DTD  using  the  IADS  Authoring  system  to  ensure  the  resulting  technical  information 
can  be  displayed  using  the  IADS  Reader.  The  IADS  DTD  is  available  by  sending  an  e-mail  to 
gramly-rg@redstone.army.mil  (Rich  Gramly). 

G.6  USMC  Point  of  Contact 

USMC  lETM  Acquisition  Policy  and  Guidance 

Mr.  Greg  Ransom 

MARCORSYSCOM  (PSD) 
ransomga®  quantico.usmc.mil 

703-784-4206 
(DSN)  278-4206 
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APPENDIX  H 

SAMPLE  lETM  CONCEPT  OF  OPERATIONS 
FOR  THE  SAGITTARIUS  SYSTEM 

The  following  is  a  sample  CONOPs  developed  for  the  Sagittarius  System,  a  conceptual  military 
program.  This  CONOPS  was  developed  by  Wayne  Honea  (NSWC-PHD)  and  copied  from  the 
Navy's  lETM  Process  Plan. 

H.l  System  Introduction 

Sagittarius  is  a  sophisticated  engagement  system  capable  of  supporting  a  wide  variety  of 
configurations,  including  various  ship  class  combat  system,  Land  Based  Test  Site,  Training,  an 
airborne  configuration  with  potential  use  by  all  US  Military  and  foreign  military  Services. 
lETM  data  will  be  maintained  and  updated  by  the  lETM  contractor  and/or  an  In-service 
Engineering  Agent  (ISEA). 

H.2  System  Attributes 

H.2.1  Complexity  of  the  System 

Sagittarius  is  comprised  of  a  sophisticated,  processor-controlled  equipment  set  that  is  capable 
of  supporting  multiple  configurations.  However,  this  equipment  incorporates  self-test  and 
operator  controlled  test  and  fault  isolation  features  that  simplify  troubleshooting  and  fault 
isolation.  The  maintenance  concept  is  "remove  and  replace."  Consequently,  there  is  no 
requirement  for  highly  complex  maintenance  guides  and  a  lower  level  of  lETMs  might  be 
acceptable.  Accordingly,  a  Class  III  type  lETM  has  been  selected  for  Sagittarius  use. 

H.3  Configuration  Volatility 

Sagittarius  is  being  designed  and  developed  as  Common  Equipment  Sets  that  have  two  baseline 
configurations;  that  is,  a  shipboard  and  an  airborne  configuration.  Due  to  the  differences 
inherent  in  airborne  and  shipboard  configuration  requirements,  two  lETMs  will  be  produced. 
The  Common  Equipment  Set  concept  minimizes  the  number  of  configurations  that  must  be 
considered  in  the  lETMs  and  reduces  lETM  change  requirements.  Structured  update  planning 
will  also  decrease  minor  differences  among  ship  classes  amount  and  frequency  of  lETM 
change  requirements. 

H.4  Classification  and  Security 

Although  some  system  parameters  and  hardware  bear  a  high  security  classification  level,  the 
lETM  will  not  contain  classified  data.  Where  necessary,  it  will  reference  documents  containing 
the  appropriate  classified  data. 

H.5  Expected  Service  Life 

Expected  service  life  of  the  Sagittarius  System  is  anticipated  to  be  on  the  order  of  20  years  with 
technological  updates  occurring  on  a  three-to-five  year  basis. 
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H.6  Number  and  Deployment  of  Systems 


The  US  Navy  will  deploy  over  200  Sagittarius  Systems.  Location  of  equipment  varies  by 
Ship/Hull.  Other  Service  and  foreign  military  requirements  cannot  be  forecast  a  this  time. 
lETM  Display  Devices  (one  in  use  and  one  backup)  will  be  required  to  support  each  Sagittarius 
System,  for  a  total,  based  on  expected  Sagittarius  Systems  deployment,  of  348  lETM  Display 
Devices.  In  addition,  it  may  be  found  necessary  to  provide  data  printing  capability,  therefore, 
cost  of  providing  graphic  capable  printers  should  be  anticipated.  Reference  the  Sagittarius 
System  fielding  schedule. 
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Initial  lETM  authoring  and  viewing  software-licensing  costs  may  be  anticipated.  Additional 
licenses  for  new  software  to  upgrade  capabilities  can  be  anticipated  at  three-to-five  year 
intervals  based  on  technology  advances. 

H.7  Number  of  lETM  Users 

The  lETM  will  serve  as  the  primary  maintenance  tool  and  source  of  technical  information 
concerning  the  Sagittarius  System  for: 

1 .  Two  Shipboard  Maintenance  Technicians  per  System. 

2.  Engineering  Support  Personnel  for  the  Fleet  Technical  Support  Centers, 
Atlantic/Pacific. 

3.  In  Service  Engineering  Agent  (ISEA)  Engineering  Support  Personnel. 

4.  Contractor  Field  Engineering  Support  Personnel 

5.  Naval  Training  Command  Schools  Personnel  and  Students. 


lETM  data  will  be  maintained  and  updated  by  the  lETM  contractor  and/or  the  ISEA. 

H.8  Quantity  of  Data 

The  Sagittarius  System  is  an  initial  procurement  of  a  technical  manual  to  be  constructed  from 
an  electronic  lETM  data  base  derived  largely  from  electronic  Logistic  Support  Aanalysis, 
LSA/LSAR  data  bases.  The  fact  that  the  Sagittarius  System  is  comprised  of  a  small  equipment 
set  and  that  the  two  basic  configuration  baselines  share  some  commonality,  limits  the  volume 
of  technical  data. 

H.9  Quality  of  Data 

The  Sagittarius  System  TM  is  as  an  initial  procurement  technical  manual  not  based  on  scanning 
and/or  re-authoring  of  legacy  hard  copy  technical  manual  data.  Initial  product  authoring  costs 
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must  be  borne.  However,  product  data  quality  is  expected  to  be  high  without  additional  quality 
improvement  re-authoring  costs. 

H.IO  Consolidation  of  Subject  Matter 

The  first  release  of  the  lETM  is  to  contain  maintenance  information  only.  Later  releases  of  the 
lETM  will  provide  electronic  OPNAV  4790/2K  submission  capability  once  SNAP  supports  the 
automated  input  of  2K  information. 

Expert  System  and  integrated  training  information  will  not  be  included  in  the  lETM.  The 
capability  of  the  equipment's  incorporated  self-  and  operator-controlled  test-and-fault  isolation 
features  allows  for  relatively  simple  remove  and  replace  procedures  to  be  performed. 

The  Airborne  lETM  and  the  shipboard  lETM  will  be  supported  by  separate  lETM  databases. 
This  is  due  to  the  significantly  different  operational  requirements  and  the  inability  of  the 
contractor's  authoring/maintenance  system  to  support  a  single  database  that  produces  two 
unique  lETM  products. 

H.ll  Maintenance  Levels 

Organizational  level  maintenance  to  be  supported  includes  fault  isolation,  overhaul,  corrective 
maintenance  (remove  and  replace),  and  scheduled  test  and  inspection  procedures.  The 
equipment's  incorporated  self  and  operator  controlled  test  and  fault  isolation  features  allow  the 
lETM  to  present  simple,  quick  to  perform  procedures. 

H.12  Training  Levels 

Due  to  the  planned  ease  of  maintenance  and  integrated  diagnostic  features,  there  are  no 
requirements  to  include  training  information  in  the  lETM.  Fleet  Training  Command  Center 
(FTCC)  will  receive  the  preliminary  EETM  for  integration  into  their  existing  paper-based 
training  curriculum.  FTCC  will  provide  lETM  operation  and  use  in  addition  to  the  standard 
curriculum.  Training  is  forecast  to  last  8-10  weeks. 

H.13  Manning  Requirements 

The  Sagittarius  System  automatic  fault  diagnostic  capabilities  will  enable  the  lETM  to  present 
quick  and  simple  maintenance  procedures.  Shipboard  manpower  surveys  indicate  no  additional 
manpower  is  required. 

H.14  Existing  Government  and  Contractor  Infrastructure 

The  Sagittarius  System  and  contractor  currently  do  not  have  lETM  authoring  tools  in  place. 
The  Sagittarius  System  will  coordinate  with  the  contractor  in  assuring  that  the  selected  lETM 
authoring  software  will  produce  and  support  SGML  data  and  the  features  required  of  the  lETM. 
It  is  expected  that  a  total  of  20  CD-ROM  drives  will  be  required  and  procured  to  prepare  the 
Sagittarius  System  Program  Office  and  ISEA  for  display  of  the  lETM.  FTCC  will  provide  the 
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Sagittarius  System  Program  Office  with  their  plan  and  resources  required  to  implement  the 
lETM  in  their  curriculum. 

Contractor  and  Sagittarius  System  Program  Office/ISEA  are  able  to  communicate  and  send 
electronic  deliverables  over  the  Internet. 

H.15  lETM  Implementation  Schedule 

The  Sagittarius  System  lETM  is  to  be  implemented  on  10  ships/training  sites/aircraft  by  June 
1998.  Approximately  30  months  are  allowed  to  implement  the  lETM.  The  lETM 
implementation  schedule  includes  developing  a  Comprehensive  Technical  Manual  Plan, 
conducting  a  Technical  Manual  Guidance  Conference,  and  determining,  to  proceed  with  lETM 
development  based  on  the  plan  and  guidance  conference  results. 

Approximately  six  months  are  allowed  to  develop  a  Comprehensive  Technical  Manual  Plan 
and  conduct  a  Technical  Manual  Guidance  Conference.  As  part  of  the  plan  development, 
available  authoring  and  viewing  systems  will  be  reviewed  and  selected.  About  four  weeks  are 
allowed  to  disseminate/review  the  Comprehensive  Technical  Manual  Plan  and  to  conduct  the 
Technical  Manual  Guidance  Conference.  The  purpose  of  this  conference  is  to  discuss  and 
reach  govemment/contractor  agreements  upon  desired  plan  changes,  and  make  a  determination 
whether  or  not  to  proceed  with  Class  III  type  lETM  implementation.  Around  24  months  are 
then  available  for  database  and  actual  lETM  development  and  in-process  reviews. 

H.16  Urgency  of  Information  Update 

Priority  changes  will  be  disseminated  to  the  Fleet  user  in  the  most  expeditious  manner  possible. 
When  safety  or  health  related,  methods  of  dissemination  could  include  naval  message, 
speedletter,  or  engineering  technical  bulletins,  dependent  upon  the  nature  and  urgency  of  the 
change.  A  process  for  direct  updating  of  shipboard  lETMs  will  be  developed. 

For  less  urgent,  large  volume  changes,  hard  copy  supplement  to  the  lETM  may  be  used  on  a 
temporary  basis  until  the  lETM  is  updated  via  a  scheduled  or,  dependent  upon  the  requirement, 
an  unscheduled  change.  Unscheduled  change  requirements  and  change  methodology  are  seen 
as  subject  to  case-by-case  determination. 

H.17  Security 

Although  the  lETM  will  contain  sensitive  information,  it  will  not  contain  classified 
information.  Access  to  lETM  data  will  be  restricted  by  a  log-in  process  that,  at  a  minimum, 
requires  the  user  to  enter  a  password. 

H.18  Display  Hardware,  Operating  Systems,  and  Networks  to  be 
Used  for  AXIS  Compatibility  Aboard  Ship 

Currently,  network  drops  are  not  available  in  the  vicinity  of  combat  and/or  weapon  system 
equipment  spaces.  Use  of  devices  such  as  the  SNAP  network  CD-ROM  jukebox  inherently 
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create  lETM  data  downloading  device  access  problems,  conflicting  user  requirements,  and 
mutual  interference  that  create  at  least  a  potential  for  equipment  maintenance  disruption. 

Future  shipboard  LAN  development  may  provide  amore  suitable  lETM  user  Infrastructure,  for 
the  immediate  future,  however  a  CD-ROM  compatible  notebook  PCs  are  the  most  feasible 
means  of  providing  this  infrastructure.  The  notebook  PC  provides  the  portability  critical  to 
effective  use  of  the  lETM  where  it  is  required,  adjacent  to  the  equipment  undergoing  tests, 
troubleshooting,  fault  isolation,  and  repair. 

H.19  Environmental  Conditions  and  lETM  Display  Hardware 

The  lETM  display  hardware  is  expected  to  be  used  in  a  high  noise  level  environment,  exposed 
to  dirt  and  grease,  and  be  subjected  to  long  hours  of  operation.  In  addition,  it  may  be  subject  to 
ship  motion  and  being  dropped  accidentally. 

H.20  Display  Hardware  Maintenance  and  Support 

Use  of  lETMs  to  support  maintenance  of  Combat  System’s  electronic  equipment  is  an  evolving 
technology.  Consequently,  there  is  little  experience  to  rely  upon  for  display  hardware 
maintenance  and  support  guidance. 

For  the  moment,  and  assuming  that  CD-ROM  compatible  notebook  PCs  are  the  display 
hardware  medium,  one  notebook  PC  for  data  display  use  and  one  notebook  PC  for  back-up  use 
is  felt  to  be  sufficient  for  a  small  electronic  equipment  employing  not  more  than  two 
maintenance  technicians.  When  a  notebook  PC  becomes  inoperative,  it  can  simply  be  replaced 
via  a  suitable  commercial  source. 
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APPENDIX  I 

ACRONYMS  AND  ABBREVIATIONS 


AAR 

After  Action  Review 

ACNs 

Advanced  Change  Notices 

ADTDL 

Army  Doctrine  and  Training  Digital  Library 

AF 

Air  Force 

AHAS 

Army  Historical  Archives  System 

AIM 

Authoring  Instructional  Material 

AIMSS 

Advanced  Interactive  Maintenance  Support  System 

AIS 

Automated  Information  Systems 

ALC 

Air  Logistics  Center 

AME 

Advanced  Maintenance  Environment 

AMIDD 

Aircraft  Maintenance  Integrated  Diagnostics  Demonstration 

AMSDL 

Acquisition  Management  Systems  Data  Requirements  Control  List 

Ascn 

American  Standard  Code  for  Information  Interchange 

ASP 

Active  Server  Pages 

ASRL 

Army  SGML  Registry  and  Library 

ATA 

Air  Transport  Association 

AXIS 

Advanced  Technical  Information  System 

BITE 

Built-in  Test  Equipment 

BCU 

Block  Cycle  Update 

CAD 

Computer  Aided  Design 

CAI 

Computer  Aided  Instruction 

CALS 

Continuous  Acquisition  and  Life-cycle  Support 

CAM 

Computer  Aided  Manufacturing 

CBI 

Computer-based  Instruction 

CBT 

Computer-based  Training 

CD-ROM 

Compact  Disk  -  Read  Only  Memory 

CD-R 

Compact  Disk  -  Recordable 

CDRL 

Contract  Data  Requirements  List 

COM 

Computer  Graphic  Metafile 

CIM 

Corporate  Information  Management 

cms 

Contractor  Integrated  Technical  Information  Service 

CMI 

Computer-Managed  Instruction 

CND 

Cannot  Duplicate 

C/NDI 

Commercial/Non  Developmental  Items 

CNET 

Chief  of  Naval  Education  and  Training 

CONOPS 

Concept  of  Operations 

CTC 

Combat  Training  Center 

DAP 

Document  Application  Profile 

DAT 

Digital  Audio  Tape 

DBMS 

Data  Base  Management  System 

DCOM 

Distributed  Component  Object  Model 

I-l 


DCSLOG 


DFARS 


DHTML 


DII 


DII-COE 


DiTO 


DLDSS 


DNS 


DoD 


DoDI 


DoDISS 


DoN 


DPS 


DSMC 


DTD 


DTMB 


EC 


EDD 


EOSS 


EPSS 


ETE 


ETM 


ETM-I 


FAR 


FEA 


FM 

FOSI 


FPSI 


FTCC 


FTP 


GCO 


GCSFUI 


GCSS 


GDMS 


GFl 


GIF 


GUI 


HC 


HTML 


HTTP 


lA 


IADS 


ICW 


ID 


Deputy  Chief  of  Staff  for  Logistics 


Defense  Federal  Acquisition  Regulation  Supplement 


Dynamic  Hyper  Text  Markup  Language 


Defense  Infrastructure  Initiative _ 

Defense  Infrastructure  Initiative  Common  Operating  Environment 


Digital  Technical  Order 


Digital  Legacy  Data  Storage  System 


Domain  Name  Services 


Department  of  Defense 


Department  of  Defense  Instruction 


DoD  Index  of  Specifications  and  Standards 


Department  of  Nav 


Defense  Printing  Service 


Defense  Systems  Management  College 


Document  Type  Definition 


David  Taylor  Model  Basin 


Electronic  Classroom 


Electronic  Display  Device 


Engineering  Operational  Sequencing  System 


Electronic  Performance  Support  System _ 

Electronic  Training  Environment 


Electronic  Technical  Manual 


Electronic  Technical  Manual  -  Interactive 


Federal  Acquisition  Regulations 


Front-End  Analysis 


FrameMaker 


Formatting  Output  Specification  Instances _ 

Formatting  Presentation  Specification  Instance 


Fleet  Training  Command  Center 


File  Transfer  Protocol 


Government  Concept  of  Operations 


General  Content,  Style,  Format  and  User  Interaction 


Global  Combat  Support  System _ 

Global  Data  Management  System 


Government  Furnished  Information 


Graphics  Interchange  Format 


Graphic  User  Interface 


Hard  Co 


HyperText  Markup  Language 


Hypertext  Transfer  Protocol 


InfoAccess 


Interactive  Authoring  and  Display  System _ 

Interactive  Courseware 


Identification 
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IDE 

Integrated  Data  Environment _ _ 

lETM 

Interactive  Electronic  Technical  Manual 

lETMDB 

Interactive  Electronic  Technical  Manual  Database 

lETMPP 

Interactive  Electronic  Technical  Manual  Process  Plan 

lETMWG 

Interactive  Electronic  Technical  Manual  Working  Group 

IG 

Instructor  Guide 

IGES 

Initial  Graphics  Exchange  Specification 

ILS 

Integrated  Logistic  Support 

IM 

Information  Manager 

IMA 

I-level  Maintenance  Activity 

IMIS 

Integrated  Management  Information  System 

INFOSEC 

Information  Security 

IPB 

Illustrated  Parts  Breakdown 

IPDE 

Integrated  Product  Data  Environment 

IPDF 

Indexed  Portable  Document  Format 

IPR 

In-Process  Review 

ISD 

Instructional  Systems  Development 

ISEA 

In-Service  Engineering  Agent 

ISO 

International  Standards  Organization 

IWSDB 

Integrated  Weapons  System  Database 

IWSM 

Integrated  Weapon  System  Management 

JCALS 

Joint  Continuous  Acquisition  and  Life-cycle  Support 

JCG-CE 

Joint  Commanders  Group  for  Communication  and  Electronics 

JEDMICS 

Joint  Engineering  Data  Management  Information  and  Control  System 

JIA 

Joint  lETM  Architecture 

JIMIS 

Joint  Integrated  Maintenance  Information  System 

jrr 

Just-in-time 

JPEG 

Joint  Photographic  Experts  Group  _ 

JSTARS 

Joint  Surveillance  Target  Attack  Radar  System 

JTA 

Joint  Technical  Architecture 

LAN 

Local  Area  Network 

LIA 

Logistics  Integration  Agency 

LO 

Lubrication  Orders 

LOAP 

List  of  Applicable  Publications 

LP 

Lesson  Plan 

LSA 

Logistic  Support  Analysis 

LSAR 

Logistic  Support  Analysis  Record 

MIL  SPEC 

Military  Specification  (e.g.,  MIL-D  for  drawings;  MIL-M  for  manuals) 

MIL-PRF 

Military  Specification  -  Performance 

MIL-STD 

Military  Standard 

MIME 

Multiservice  Internal  Mail  Extensions 

MRC 

Maintenance  Requirement  Cards 

MWO 

Maintenance  Work  Orders 

NALCOMIS 

Naval  Aviation  Logistics  Command  Management  Information  System 
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NATSF 


NAVAIR 


NAVEDTRACOM 


NAVSEA 


NAWCTSD 


NDOI _ 

NIFF 


NIRS 


NOI 


NPRDC 


NTIPS 


NSDSA 


NSN 


NAVSEA 


NSTM 


NSWC 


NSWC-CD 


NSWC-PHD 


NTCSS 


OCR 


ODA 


OMLE 


O&M 


OS 


PAM 


PC 


PDF _ 

PEDD 


PFE 


PMA 


PMS _ 

PPP 


_QA _ 

RAC 


RCS 


RDBMS 


RFP _ 

RIA _ 

RPSTL 


R&R 


SAMS 


SB 


SEAADSA 


SECDEF 


Naval  Air  Technical  Services  Facilit 
Naval  Air  Systems  Command 


Naval  Education  and  Training  Command 


Naval  Sea  Systems  Command 


Naval  Air  Warfare  Center  Training  Systems  Division 


Non-Developmental  Item 


Navy  Image  File  Format 


Navy  Implementation  of  Raster  Scannin 


Non-Developmental  Item 


Naval  Personnel  Research  and  Development  Center 


Navy  Technical  Information  Presentation  System 


NAVSEA  Data  Support  Activit 


National  Stock  Number 


Naval  Sea  Systems  Command 


Navy  Ships  Technical  Manual 


Naval  Surface  Warfare  Center _ 

Naval  Surface  Warfare  Center  -  Carderock  Division 


Naval  Surface  Warfare  Center  -  Port  Hueneme  Division 


Navy  Tactical  Command  Support  System 


Optical  Character  Reader 


Office  Document  Architecture _ 

Omnimark  Limited  Edition _ 

Operational  &  Maintenance 


Output  Specification 


Pamphlet 


Personal  Computers _ 

Portable  Document  Format 


Portable  Electronic  Display  Device 


Program  File  Editor 


Portable  Maintenance  Aid 


Preventive  Maintenance  Subsystem _ 

Personnel  Performance  Profile 


Quality  Assurance _ 

Rapid  Action  Changes 


Radio  Communication  Set 


Relational  Database  Management  System 


Request  for  Proposal 


Related  Instructor  Activities 


Repair  Parts  and  Special  Tools  List 


Remove-and-replace 


Standard  Army  Maintenance  System 


Supply  Bulletins 


NAVSEA  Automated  Data  Systems  Activif 


Secretary  of  Defense 
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SGML 


SIM 


SM 


SME 


SNAP 


SOO 


SOP 


SOW 


SPAM 


SPAWAR 


SSES 


SSMs 


TADSS 


TB 


TCM 


TCTO 


TG 


TCP-IP 


TIC 


TIDES 


TIFF 


TIMS 


TM 


TMARC 


TMCR 


TMDER 


TMIN 


TMINS 


TMMA 


TMMP 


TMPODS 


TMSS 


TO 


TOCO 


TOCR 


TPS 


TSA 


TSP 


ULLS 


URL 


USAF 


USAPA 


USMC 


USN 


Standard  Generalized  Markup  Language _ 


Supporting  Information  Chapter  _ 


Single  Manager  _ 


Subject  Matter  Expert _ 

Shipboard  Non-tactical  Automated  Data  Processing  Program 

Statement  of  Objectives _ _ 

Standard  Operating  Procedures  _ 


Statement  of  Work 


SP  Added  Marku 


Space  and  Warfare  Systems  Command  _ 


Ship  Service  Engineering  Station _ _ 


Ships  Service  Manuals  _ 


Training  Aids,  Devices,  Simulations  and  Simulators _ 


Technical  Bulletins  _ 


Technical  Content  Manager  _ _ 


Time  Compliance  TO 


Trainee  Guide  _ _ 

Transmission  Control  Protocol/Intemet  Protocol 


Troubleshooting  Information  Chapter  _ 


Technical  Information  Deficiency  Evaluation  System  _ 


Tagged  Information  File  Format  _ 


Training  Integration  Management  Software  _ 


Technical  Manual  _ 


Technical  Manual  Acquisition  Requirements  Checklist 


Technical  Manual  Contract  Requirements _ 


Technical  Manual  Deficiency  Evaluation  Report _ 


Technical  Manual  Identification  Number _ _ 

Technical  Manual  Identification  Numbering  System _ 

Technical  Manual  Management  Activit 


Technical  Manual  Management  Program _ 


Technical  Manual  Publish  On  Demand  System 


Technical  Manual  Specifications  and  Standards _ 


Technical  Order _ _ 


Technical  Order  Conversion  Operation _ 


Technical  Order  Contract  Requirement _ 


Training  Path  System _ 


Training  Support  Agent  _ 


Training  Support  Packages  _ _ _ 


Unit  Level  Logistics  System  _ 


Uniform  Resource  Locator  _ 


United  States  Air  Force 


United  States  Army  Publishing  Agenc; 


United  States  Marine  Corps  _ _ _ _ 


United  States  Nav’ 


USPRO 

U.S.  Product  Data  Association 

v&v 

Verification  &  Validation 

VP 

View  Package 

vURL 

virtual  Uniform  Resource  Locator 

WAN 

Wide  Area  Network 

WWW 

World  Wide  Web 

WYSIWYG 

What-you-see-is-what-you-get 

W3C 

World  Wide  Web  Consortium 

XML 

extensible  Markup  Language 
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APPENDIX! 

LIST  OF  SOURCES 

In  addition  to  the  numerous  Web  sites,  policy  manuals,  specifications,  standards  and  vendor 
supplied  information,  the  following  resources  served  as  the  basis  for  much  of  the  material 
presented  in  this  document. 

Draft  lETM  Process  Plan 
Wayne  Honea 
NSWC-PHD 
February  1998 

Interactive  Electronic  Technical  Manuals  Cost/Benefit  Analysis 
Hughes  Technical  Services  Corporation 

Joint  lETM  Architecture 
Eric  Jorgensen 
NSWC,  Carderock  Division 
July  1998 

Maintenance  and  Logistic  System  Support  Benefits  Resulting  From  Introduction  of  lETM 

Based  Technology 

NSWC-CD/TSS-97/02 

Joseph  Fuller 

Samuel  C.  Rainey 

Theodore  J.  Post 

October  1996 

NAVSEA/SPAWAR  lETM  Process  Plan 

S0005-AD-PRO-010 

Wayne  Honea 

December  1995 
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